[Bug binutils/12549] New: --as-needed should ignore weak references

[ossman at cendio dot se]

http://sourceware.org/bugzilla/show_bug.cgi?id=12549

           Summary: --as-needed should ignore weak references
           Product: binutils
           Version: 2.21
            Status: NEW
          Severity: normal
          Priority: P2
         Component: binutils
        AssignedTo: address@hidden
        ReportedBy: address@hidden


Created attachment 5276
  --> http://sourceware.org/bugzilla/attachment.cgi?id=5276
binutils-2.20-weak-as-needed.patch

This is a bug entry for the following thread:

http://sourceware.org/ml/binutils/2010-04/msg00246.html

The basic problem is that on Solaris you easily get programs depending on
libgcc_s even though they do no really need any symbols from it. We considered
this a bug and fixed binutils to behave the way it does on Linux (glibc)
systems.

Initial message with the details:

I'm struggling with a bit of a problem when using the GNU toolchain
for a solaris target. This seems to be a fairly well known issue as
it's the basis for the USE_LD_AS_NEEDED thing in gcc. Unfortunately the
problem still isn't fully solved, so I was hoping to get some input and
hopefully progress this further.

The basic problem is:

 - On non-glibc systems, crtbegin.o (from gcc) references
   __register_frame_info. It does this always, even though it's only
   really needed for exception handling. To alleviate this, the
   references are marked as weak and the code is written to handle
   these not getting resolved by the linker.

 - When linking together a DSO, gcc will always add -lgcc_s and ld will
   (correctly) add this as a dependency and will satisfy the
   __register_frame_info references. Let's call this DSO libfoo.

 - Linking a program does _not_ make gcc append -lgcc_s, so normally
   you wouldn't get that unnecessary dependency. But linking a program
   that uses libfoo makes ld follow the DT_NEEDED of it and put up
   libgcc_s on the list of DSOs to check. Since the program will also
   have crtbegin.o, with the weak __register_frame_info reference in
   it, ld will add libgcc_s to the program as DT_NEEDED.

End result is that you have programs depending on libgcc_s even though
they do not use exception handling, complicating the deployment to
non-glibc systems.

This wasn't really acceptable to us, so we/I started looking at how to
make binutils and gcc do the correct thing. Since libgcc_s is needed in
some cases (like with g++), the key issue seem to be to make the
toolchain better respect the weak references. Two things are needed
here:

 - gcc uses --as-needed on Linux systems around -lgcc_s, hoping that ld
   would do the right thing<tm>. Unfortunately it didn't for non-glibc
   systems, so these days only glibc 2.2+ systems get this flag. My
   first step was reinstating this flag for every system that supported
   it.

 - The wrong thing<tm> that ld did was to consided libgcc_s as needed,
   even though it only satisfied weak references. After a lot of
   horrifying digging through binutils internals, I managed to make it
   not consider DSOs with only weak references to it as needed.

Now this is now well behaved for this scenario, but is there some other
scenario that will break because of this? The documentation doesn't
mention how --as-needed and weak symbols interact, so it's currently
somewhat undefined. If not then I'd really appreciate if the patch
below could get merged.

There is a fixme in there about references from DSOs that I'm not sure
what's implied. I'm also not entirely clear on why ld's adding
DT_NEEDED to the program to satisfy unresolved symbols from a DSO.
Shouldn't it be up to the DSO to have whatever DT_NEEDED it requires to
fix up its dependencies?

-- 
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.