This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


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

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)


   Date: Mon, 17 Jul 2000 09:13:20 -0700
   From: "H . J . Lu" <hjl@valinux.com>
   Cc: Geoff Keating <geoffk@cygnus.com>, kettenis@wins.uva.nl,
      drepper@cygnus.com, law@cygnus.com, rth@twiddle.net,
      libc-hacker@sourceware.cygnus.com, gcc@gcc.gnu.org
   Content-Disposition: inline
   User-Agent: Mutt/1.2.2i
   Content-Type: text/plain; charset=us-ascii

   On Mon, Jul 17, 2000 at 05:59:22AM -0300, Alexandre Oliva wrote:
   > On Jul 14, 2000, Geoff Keating <geoffk@cygnus.com> wrote:
   > 
   > > [aoliva said:]
   > 
   > >> Despite the minor problem of how to bootstrap this situation.
   > 
   > > You can have circular dependencies involving libc.
   > 
   > Yup.  I was talking about how to *create* the libraries in such a way
   > that each one uses the appropriate SONAME to refer to the other.  As I
   > said, no big deal, it just has to be done carefully.
   > 

   I am doing some experiments on the shared libgcc. I have added
   -Wl,--auxiliary,libgcc.so.3 when building my libc.so. I created a
   shell script, updatelibgcc. updatelibgcc takes CC and slibdir from
   environment to build/install libgcc.so.3. It seems to work so far.

   One interesting thing I noticed that libgcc.so might not be needed
   at all under Linux. I don't like the explicit dependency on libgcc.so.
   Can someone tell me if there is a case --auxiliary libgcc.so.3 is not
   enough for Linux? I may have missed something.

Let me refresh your mind:

 1. We have __deregister_frame_info, __register_frame_info,
    __frame_state_for, etc. in libc.so.

 2. A single copy of these functions must be used in every program.

 3. It might be necessary to change the implementation (while
    maintaining backwards compatibility) of these functions to support
    new versions of GCC.  This implies that the single copy mentioned
    above must be the most recent copy.

 4. We don't want to force everybody to recompile or even upgrade libc
    whenever they install a new version of GCC.

The only reliable solution that has been found thus far is putting
these functions in a shared library that can be upgraded (in principle
when installing a new version of GCC) whenever needed.

Now if point 3 above includes adding any new interfaces, having that
shared library as a DT_AUXILIARY of libc.so isn't enough.  Any objects
that make use of that new functionality (presumably because they have
been compiled with the new GCC) will have to be explicitly linked with
that shared library.

The EH frame info issue isn't the only problem with the current
libgcc.a that might be solved by introducing a shared libgcc.  Right
now symbols from libgcc.a that are used in code in a shared library
(say libfoo.so) are usually reexported from that shared library.

This means that binaries linked against libfoo.so that also
need those symbols, contain undefined references to those symbols.
Now if you change the implementation of libfoo.so such that it doesn't
need those symbols from libgcc.a anymore and install this new version
(that's otherwise supposed to be still binary compatible) your program
won't run anymore.

The solution proposed by the GCC folks is simply to put everything in
libgcc.a into libgcc.so and link every program or shared library with
libgcc.so.  This indeed guarentees that you never see this problem,
and is likely to work on most platforms that support shared libraries.
Unfortunately this introduces an explicit dependency for every program
on yet another shared library.  There have been several people who
said they didn't like that, myself included.  Having to distribute a
shared library with all binaries is a PITA and might lead to people
statically linking their programs to avoid this.  There also may be of
performance penalty with using the libgcc functions from a shared
library

I think that with on Linux and the Hurd, with the current GNU tools we
can do a little better.  The reexportation problem can be controlled
using STV_HIDDEN/STV_PROTECTED.

Mark

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