[Bug binutils/22769] crash when running 32-bit objdump on corrupted file
https://sourceware.org/bugzilla/show_bug.cgi?id=22769 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |2.31 --- Comment #2 from Alan Modra --- Fixed -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/22769] crash when running 32-bit objdump on corrupted file
https://sourceware.org/bugzilla/show_bug.cgi?id=22769 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f2023ce7e8d70b0155cc6206c901e185260918f0 commit f2023ce7e8d70b0155cc6206c901e185260918f0 Author: Alan Modra Date: Thu Feb 1 18:01:00 2018 +1030 PR22769, crash when running 32-bit objdump on corrupted file PR 22769 * objdump.c (load_specific_debug_section): Check for overflow when adding one to section size for a string section terminator. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22762] missing static variable constructor calls
https://sourceware.org/bugzilla/show_bug.cgi?id=22762 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Domani, Are you saying that that commit broke static constructors ? This would imply that the placement of the __CTOR_LIST__ symbol in libgcc(_ctors.o) is incorrect, so that when the start up code runs, it looks at the data pointed to by __CTOR_LIST__, finds nothing, and so no constructors are run. Please could you have a look at the executable to see if this is the case ? (Or upload it to this PR so that I can have a look at it). Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22762] missing static variable constructor calls
https://sourceware.org/bugzilla/show_bug.cgi?id=22762 --- Comment #2 from Domani Hannes --- > Are you saying that that commit broke static constructors ? Yes, exactly. > This would imply that the placement of the __CTOR_LIST__ symbol in > libgcc(_ctors.o) is incorrect, so that when the start up code runs, > it looks at the data pointed to by __CTOR_LIST__, finds nothing, and > so no constructors are run. Please could you have a look at the > executable to see if this is the case ? (Or upload it to this PR > so that I can have a look at it). __CTOR_LIST__ is empty in this case, I checked in the debugger already. And once I remove those PROVIDE()'s again, everything works again. PS: Originally I had opened this gdb bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22757 Someone mentioned there that I'm not the only one with this problem with the new binutils version. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22762] missing static variable constructor calls
https://sourceware.org/bugzilla/show_bug.cgi?id=22762 --- Comment #3 from Nick Clifton --- Hi Domani, > And once I remove those PROVIDE()'s again, everything works again. > > PS: Originally I had opened this gdb bug: > https://sourceware.org/bugzilla/show_bug.cgi?id=22757 > Someone mentioned there that I'm not the only one with this problem with the > new binutils version. The thing that concerns me is that this might not be a binutils bug. It might be a bug in gcc's libgcc.c file that is used to create ctors.o. That is why I wanted to have a look at the failing executable, so that I can see if the __CTOR_LIST__ symbol really is in the wrong place. So - please could you upload the compiled test case ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22762] missing static variable constructor calls
https://sourceware.org/bugzilla/show_bug.cgi?id=22762 --- Comment #4 from Domani Hannes --- Created attachment 10766 --> https://sourceware.org/bugzilla/attachment.cgi?id=10766&action=edit compiled testcase used options: > g++ -g -ostatic-var.exe static-var.cpp -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/22770] New: [MIPS] GOLD fails to link ghc: internal error in get_got_page_offset, at gold/mips.cc:6271
https://sourceware.org/bugzilla/show_bug.cgi?id=22770 Bug ID: 22770 Summary: [MIPS] GOLD fails to link ghc: internal error in get_got_page_offset, at gold/mips.cc:6271 Product: binutils Version: 2.30 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: jcowgill+sourceware at jcowgill dot uk CC: ian at airs dot com Target Milestone: --- Created attachment 10767 --> https://sourceware.org/bugzilla/attachment.cgi?id=10767&action=edit objects.tar.xz From: https://bugs.debian.org/886222 The GOLD linker fails to link GHC on the 3 mips Debian architectures. Using the BFD linker works. It seems to fail in previous binutils versions as well so I don't think this is a regression. The original link command is very large, but I have at least managed to get the input objects down to around 24MB worth of objects (attached). Ignore all the undefined references which come from missing objects I have removed. Simply linking the objects together: ld objects/* Gives: > [...] > Syntax.p_o:ghc_3.p_hc:function s1oJN_entry: error: undefined reference to > 'base_GHCziShow_zdfShowZLz2cUz2cUZRzuzdsgo2_entry' > Syntax.p_o:ghc_3.p_hc:function s1oMG_entry: error: undefined reference to > 'base_GHCziShow_zdfShowZLz2cUz2cUZRzuzdsgo2_entry' > Syntax.p_o:ghc_3.p_hc:function s1oMT_entry: error: undefined reference to > 'base_GHCziShow_zdfShowZLz2cUz2cUZRzuzdsgo2_entry' > ../../build-mips/gold/ld-new: internal error in get_got_page_offset, at > ../../binutils-gdb/gold/mips.cc:6271 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/22771] New: nm does not display line information for uninlined copies of functions
https://sourceware.org/bugzilla/show_bug.cgi?id=22771
Bug ID: 22771
Summary: nm does not display line information for uninlined
copies of functions
Product: binutils
Version: 2.30
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: pcarroll at codesourcery dot com
Target Milestone: ---
Created attachment 10768
--> https://sourceware.org/bugzilla/attachment.cgi?id=10768&action=edit
Possible patch to nm for this issue
The nm utility supports -l for using debug information to obtain file and line
information for each symbol.
When a source is compiled with -O2, functions can be inlined. The compiler
also produces an uninlined copy of the function, normally for use by other
files.
In the case of DWARF2 debug information, the compiler generates debug
information to describe the function. It then references that debug
information from the inlined and uninlined copies of the routine through the
use of the DW_AT_abstract_origin reference.
When nm is used on such a file, it is not able to find file and line
information because that information is present at the common debug information
and not at each actual implementation of the function.
What I am proposing is to modify the find_abstract_instance_name() function
(which I renamed to find_abstract_instance() ) to return the name of the
function as well as file and line information. The routine is already parsing
all of the debug information in the abstract instance, so it is easy to pick up
the file and line information at that time.
For example, if I have a simple test case:
int foo(int j)
{
if (j < 15)
j += j << 2;
else if (j < 30)
j += j << 4;
else
j += j << 6;
return j;
}
int main (int argc,char **argv)
{
int i = argc;
i += foo(i);
return i;
}
If that test case is compiled and then 'nm -l' reads that executable, it
currently produces this symbol output (ignoring a lot of library symbols):
8048400 T foo
080482e0 T main /scratch/pcarroll/its254/test/mytest.c:12
If I modify 'nm' to return file and line information for abstract instances, it
produces the following output:
08048400 T foo /scratch/pcarroll/its254/test/mytest.c:1
080482e0 T main /scratch/pcarroll/its254/test/mytest.c:12
I am attaching my proposed patch.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22762] missing static variable constructor calls
https://sourceware.org/bugzilla/show_bug.cgi?id=22762 --- Comment #5 from Nick Clifton --- Hi Domani, Thanks. So the __CTOR_LIST__ symbol is indeed wrong - it is pointing to somewhere in the middle of the .bss section. It looks to me like the culprit is the _ctors.o file. Would you mind uploading that too, so that I can take a look at it ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22762] missing static variable constructor calls
https://sourceware.org/bugzilla/show_bug.cgi?id=22762 --- Comment #6 from Domani Hannes --- Created attachment 10769 --> https://sourceware.org/bugzilla/attachment.cgi?id=10769&action=edit _ctors.o -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22762] missing static variable constructor calls
https://sourceware.org/bugzilla/show_bug.cgi?id=22762 --- Comment #7 from Nick Clifton --- Hi Domani, Thanks for the _ctor.o file. I think that I understand the problem now. The _ctor.o file defines the __CTOR_LIST__ symbol as a common symbol (ie uninitialized). These symbols can be overriden by a definition that does define a value, which is why the linker scripts used to work in the past. But the addition of the PROVIDE directive changed that, because PROVIDE will not override a common symbol. Hmm, I need to think about how to fix this. In the meantime please could you see if adding: -Wl,--defsym,__CTOR_LIST__=.ctors to your command line will act a workaround for the problem ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22762] missing static variable constructor calls
https://sourceware.org/bugzilla/show_bug.cgi?id=22762 --- Comment #8 from Hannes Domani --- (In reply to Nick Clifton from comment #7) > In the meantime please could you see if adding: > > -Wl,--defsym,__CTOR_LIST__=.ctors > > to your command line will act a workaround for the problem ? Then I get this result: > $ g++ -ostatic-var.exe static-var.cpp -Wl,--defsym,__CTOR_LIST__=.ctors > c:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/../../../../i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-gccmain.o): > reference to ___CTOR_LIST__ > c:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/7.3.0/libgcc.a(_ctors.o): > definition of ___CTOR_LIST__ > --defsym:1: undefined symbol `.ctors' referenced in expression > collect2.exe: error: ld returned 1 exit status But I've just removed the PROVIDE()'s to make it work again, that's good enough as a workaround for me. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
