[Bug gold/12910] New: gold doesn't create .init_array from .ctors

[roland at gnu dot org]

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: address@hidden
        ReportedBy: address@hidden


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.