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: [email protected]
ReportedBy: [email protected]
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
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-binutils
