The DT_AUXILIARY patch

[Mark Kettenis]

   Date: Sat, 15 Jul 2000 11:07:26 -0700
   From: "H . J . Lu" <hjl@lucon.org>

   On Sat, Jul 15, 2000 at 07:48:17PM +0200, Mark Kettenis wrote:
   >    Date: Sat, 15 Jul 2000 10:03:41 -0700
   >    From: "H . J . Lu" <hjl@lucon.org>
   > 
   >    On Sat, Jul 15, 2000 at 03:20:23PM +0200, Mark Kettenis wrote:
   >    >    Date: Fri, 14 Jul 2000 18:31:28 -0700
   >    >    From: "H . J . Lu" <hjl@lucon.org>
   >    > 
   >    >    BTW, we just need to make sure everything exported from the shared
   >    >    libgcc is also exported from libc.so. I think we will be safe then.
   >    > 
   >    > That would be an incredibly stupid thing to do, since it means that
   >    > you'd have to recompile glibc whenever things are added to libgcc.so.
   >    > 
   > 
   >    That is true. The isse is we need to find a way to make the references
   >    to those exported symbols in libgcc.so dynamic. That is what libgcc.so
   >    is used for. How about we teach ld to check DT_AUXILIARY? It will
   >    be treated as DT_NEEDED for that purpose. ld won't wont propagate
   >    DT_AUXILIARY to anything else.
   > 
   > Argh!  No!  The current behaviour of ld to walk the DT_NEEDED list
   > when resolving symbols from shared libraries has its problems and is
   > incompatible with at least the Solaris linker.  See
   > < http://sources.redhat.com/ml/binutils/1999-11/msg00037.html > for a

   I didn't find the original message. Is the original problem solved?
   I ran into a similar problem with OpenGL. One OpenGL implmenentation
   is multi-threaded. But it has to work with single thread applications.
   That means the OpenGL implmenentation has to make sure libpthread.so
   is always available even if it is used with a single thread application.
   I had to fix a bug in glibc to make things to work for them. I can ask
   them to see how they solved the problem.

Here is link to the message with details about the origional problem:

http://x40.deja.com/getdoc.xp?AN=545891503&CONTEXT=958448712.1788280849&hitnum=29

The "bug" isn't fixed.  It's one of those "BUG IN DYNAMIC LINKER"
cases where there's a corrupt/inconsistent binary.  The dynamic linker
is complaining about the fact that there is a version dependency for a
library that's not in the applications DT_NEEDED list, and it has
every right to do so.

The right fix is to stop the static linker from walking the DT_NEEDED
list (at least when recording versioning information, but in principle
altogether).  The old behaviour should probably still be available,
when activated by a special switch.

   > discussion.  Adding this for DT_AUXILIARY makes even less sense.  If
   > the library in DT_AXUILIARY is absent everything should still work.
   > Our proposed use of DT_AUXILIARY is more or less abusing the concept.
   > It seems to work, but isn't really appropriate.  Let's not bias our
   > tools too much to this particular use.

   As I said, ld will check DT_AUXILIARY for setting a symbol dynamic.
   That means you don't need to use "gcc -rdynamic". I will make sure it
   won't have any other bad side effects.

Can't you see that this is even worse than the DT_NEEDED case
illustrated above.  An object for which we have a DT_AUXILIARY entry
is allowed to be completely absent.  That's why making libgcc.so a
DT_AUXILIARY of libc.so is such a nasty hack.  If some functionality
is added to libgcc.so (for example support for a new DWARF symbol),
it's not guaranteed that programs compiled with a new version of GCC
will still run if the appropriate libgcc.so isn't present.

   > 
   >    > there too.  Of course this can be postponed until you actually add
   >    > new stuff to libgcc.so.
   > 
   >    I don't like libgcc.so since it will introduce explicit dependency
   >    on libgcc.so and with DT_AUXILIARY, the only thing we need is to
   >    make the references to to those exported symbols in libgcc.so dynamic.
   >    Without libgcc.so, the resulting binaries will run ok with the slightly
   >    older libc.so which has no DT_AUXILIARY as long as the ABI of libgcc
   >    is not changed too much.
   > 
   > Nasty, isn't it?  That's why I said you could postpone explicitly
   > linking against libgcc.so until the ABI of libgcc actualy changes.
   > However, as soon as it does, you'll have no other choice.

   That is what I want to avoid.

That can only been done in a limited number of cases.

   > In principle, there is no need for the shared libgcc.so at all as long
   > as you don't use exception handling.  So perhaps it is possible to
   > tweak things (using linker tricks and the GCC specs file) to avoid the
   > explicit dependency on libgcc.so for plain C programs.

   That won't work since there is no way to tell if any C++ codes exist
   or not. I can even implement glibc in C++ as long as I support the
   glibc ABI.

It will work fine.  Code compiled without -fexceptions doesn't have
any frame info to register, and won't call any exception handling
functions.  So it doesn't need any of the functionality provided by
libgcc.so.

If you have a certain shared library, say libfoo.so, that's currently
compiled without -fexceptions and reimplement libfoo.so in C++, you'll
have to link the library against libgcc.so[1].  But any existing programs
that were linked with libfoo.so, will continue to work as before.

[1] Of course the compiler driver should do this automagically.

Mark