This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

rfc: guessing when a shared libgcc is needed

As has been discussed before:

It would not really be a good thing if we always linked against
the shared libgcc, since that forces Fred to give Barney a copy
of libgcc whenever he gives him any other random executable.
If they are just using C on Solaris, there is no reason for this
extra dependancy.

The following are some guidelines that I propose to start with
when deciding to use a shared libgcc:

  * We want to use dlopen to dynamicly load modules.  This is generally
    recognizable by using --export-dynamic, or linking against libdl.

    It is possible, of course, that something could be known about the
    nature of the modules that they will never need exception handling.
    But some will, and turning shared libgcc on is the safe default.

  * The program links (perhaps indirectly) against some DSO that uses
    the shared libgcc.

  * We are building a DSO that uses any EH function.

At this time, this last clause is true for any shared library that
we build, since crtbegin calls __register_frame_info.  However, I
think that can be fixed in two ways:

 (1) IA-64 creates a program header that points to the unwind info
     for that DSO.  With a small amount of coordination with,
     it is possible to locate all of the unwind information without
     any calls to __register_frame_info at all.  This is most 
     excellent, since it means that we'd only need the shared libgcc
     linked to DSOs that actually call __throw or its ilk.

     For systems in which we control linking and such, it would be
     relatively easy to modify ld to do the same trick with the
     dwarf2 unwind sections.

 (2) If that's not viable, then we can change how crtbegin works.
     Namely, split it into two different files (crtbegin and crtframe),
     and only link in crtframe if the resulting DSO would have had
     a non-empty unwind section.  That is, we don't need to register
     unwind information if there's nothing in it.

     The simplistic way to do this is to link the binary once, examine
     the unwind section and if it's not empty, relink.  A faster way
     would be to scan the object files and archives first, assuming 
     that if any archive member contains unwind info that they probably
     all do.

     Generally this would remove the only reference to EH widgetry
     from C shared libraries.

I've not tried either of these schemes yet.

The following is a mock-up of code that implements these rules.
It accepts --shared-libgcc-name=<some soname>, plus several of
ld options -rpath, -rpath-link, -l, -L, -Bshared, -Bstatic, etc.
It prints 0 if a shared libgcc is not needed and 1 if so.

Ignore the fact that this code is not written portably at the moment.
A proper implementation would use the bits from include/elf/ in the
binutils distribution. [1]

Ignore the fact that I've hardcoded config.h for my alpha.  Most
of these options come from gcc configury already.

The question here is where to put the code?  collect2 is the obvious
choice, but that is, IMO, frought with peril -- collect2 is some of
the grossest code in the distribution.

The option that I'm sort of fond of at the moment is to put the
thing in the gcc driver directly.  There, we've not yet gotten lost
in the quagmire that is ld option parsing.  We also don't have to
play games with environment variables to pass non-ld options to the
child process.

But if that's not considered kosher, we could use a separate program
that the gcc driver invokes that does nothing but determine that the
shared libgcc is needed, leaving it to the driver to substitute the
shared libgcc onto the link line.



[1] On a related note, one could (almost) use bfd for this instead of
poking elf directly.  Almost, because at present you can't get at
things like the program headers, and you'd still have to do direct
ELF mucking with _DYNAMIC.  But this may be an option for non-elf
systems. [2]

[2] On a related note, this may force us to combine the binutils and
gcc repositories, which we've been threatening to do for a while.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]