http://sourceware.org/bugzilla/show_bug.cgi?id=12910
Summary: gold doesn't create .init_array from .ctors Product: binutils Version: 2.22 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gold AssignedTo: i...@airs.com ReportedBy: rol...@gnu.org For a trivial case such as: gcc -fPIC -shared -o ctor.so -xc <(echo 'static void __attribute__((constructor)) foo(void) { puts("foo"); }') gcc will generate a .ctors section. Current GNU ld on x86_64-linux will automagically fold the contents of .ctors (omitting the .ctors sections coming from input files named crtbegin{,?}.o, sigh) into a .init_array output section, that is SHT_INIT_ARRAY and generates DT_INIT_ARRAY{,SZ}. Gold does not do this. Constructors still run, because the crt{begin,end} files define an .init section that looks at .ctors. Under GNU ld, the contents of .ctors sections from all other files have been sucked away into the .init_array section, so the output .ctors that .init's code uses is just a stub with no entries. Hence, constructors only get run once, even though there is both DT_INIT and DT_INIT_ARRAY. However, eventually one would like to get rid of crt{begin,end} entirely for a compiler configuration where you know you have a linker that will produce .init_array. In that event, gold's lack of magic would be the limiting factor. Perhaps it's really the case that the compiler eventually should be taught to just emit into a proper .init_array directly rather than into .ctors, and then no magic whatsoever beyond SHT_INIT_ARRAY matching would be required of a linker. But as things stand, gold is behind GNU ld here. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- 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