What to put in a shared libgcc

What to put in a shared libgcc

[Mark Kettenis]

[Sorry folks, tried to send this to gcc@gnu.org instead of
gcc@gcc.gnu.org :-(]

Here's an analysis of the modules in libgcc.a for GCC 2.95.2 on
i586-pc-linux-gnu.  Feel free to put this up on the gcc web pages if
you like (linked to the libgcc.so discussion page or so).

Based on this analysis, I think the only stuff that should be moved
into a shared libgcc on Linux/x86 is the frame registration stuff
(frame.o) and probably parts of the language-independent exception
handling stuff (libgcc.2[L_eh], i.e. the stuff that ends up in _eh.o).

I left out the arithmetic support functions (such as __ashldi3,
__floatdixf, etc.).  These can go anywhere we like.  That probably
means keeping them in the libgcc archive, provided we can address the
problem of reexporting themfrom shared libraries created with GCC,
which at least on Linux, I think we can.

The reason for putting as little stuff in the shared libgcc as
possible, is simple.  It's much easier to control a small ABI than a
large one.  And one can only add stuff, not remove.

OK here we go.  For some modules I provide the list of global symbols
as reported by nm:

__dummy.o:
00000000 T __dummy

Could this be, eh..., a dummy function?  We can put this wherever we
want.

__gcc_bcmp.o:
0000003b t Letext
00000000 T __gcc_bcmp

Multiple copies don't matter, we can put this obe weherever we want.

_bb.o: 

Functions for basic block profiling.  I don't think these
belong in the shared libgcc.  Profiling isn't something that is
supposed to be done on installed/distributed binaries, so binary
compatibility isn't a problem.

_eh.o:

Functions for exception handling.  I'm not sure about these.  If there
isn't a stable interface for this stuff it shouldn't be added to the
shared libgcc.  If the interface is stable, and the ABI is considered
fixed, this might be added to the shared libgcc.  That might even be
essential to prevent problems from a mismatch with the frame
registration functions.  The presence of __terminate_func also suggests
it might be a good idea.  Otherwise set_terminate() might suffer from
amnesia if additional shared libraries are being dlopen()'ed.

There are plans to use some of this stuff in glibc to implement
pthreads cleanup handlers, in order to let them do the right thing for
multithreaded C++ programs.  In that case the interaction with glibc's
libpthread.so is important too.  Putting things in the shared libgcc
probably avoids any problems.

Is there any reason to put setjmp/longjmp exception handling in the
shared libgcc when DWARF2 unwind info is available?  I don't think
so since it's non-standard.  The sj stuff doesn't need the frame stuff

By the way, is there any reason why __default_terminate() isn't
static?  Or empty() for that matter.  It looks like it isn't
referenced anywhere in the GCC tree, except in the libgcc2.c [L_eh]
itself.  Is this part of an undocumented interface of some sorts or
just an oversight?

_eprintf.o:
00000000 T __eprintf
         U abort
         U fflush
         U fprintf
         U stderr

Better left in the archive.  It's certainly not essential that a
single copy of __eprintf() is used.  This function references abort(),
fflush(), fprintf() and stderr.  The interface of these is dictated by
ISO C, and only depends on the sizeof (int) and sizeof (FILE *).  If
this ends up in a shared library the references will be bound to a
specific version if we link with libc, or to the base version.

_pure.o:
00000000 T __pure_virtial
         U __terminate

The same argument as fot _eprintf.o applies.

_shtab.o:
00000000 D __shtab

Multiple copies may be used.  Doesn't matter where this ends up.

_varargs.o:
00000000 T __builtin_saveregs
         U abort

Multiple copies may be used.  Doesn't really matter where this ends
up, although the argument used with _eprintf.o may be applied to
prefer leaving it in the archive.

exception.o:

Depends on the C++ ABI.  Should therefore not end up in the shared
libgcc.  Probably (parts of) it should be moved into a C++-specific
runtime library.

frame.o:

00000cbc T __deregister_frame
00000c04 T __deregister_frame_info
00000cec T __frame_state_for
00000b20 T __register_frame
00000aa0 T __register_frame_info
00000b54 T __register_frame_info_table
00000bd0 T __register_frame_table
         U abort
         U free
         U malloc
         w pthread_create
         w pthread_getspecific
         w pthread_key_create
         w pthread_key_delete
         w pthread_mutex_lock
         w pthread_mutex_trylock
         w pthread_mutex_unlock
         w pthread_once
         w pthread_setspecific

Functions for EH frame info registration.  This is the module that
started all the trouble.  There has to be a single copy of this module
in the entire process.  The module may be completely absent in
programs that don't use exception handling, i.e. programs that never
call __frame_state_for.  That's why GCC's crtstuff.c goes to some
trouble with weak references to __register_frame_info and
__register_frame_table, although I'm not sure if that has the desired
effect right now.

I think the consensus is that the only chance of having exception
handling work correctly on systems with shared libraries is to put
this module in a shared libgcc.

I'm a bit worried though about the fact that this program references
pthreads functions.  This means that changing the ABI for these
functions in libc might have disastrous consequences.  And since
pthread_mutex_t isn't an opaque type, and might need to be extended to
support new mutex attributes, changing the ABI may become necessary.
Perhaps we should formalize an alternative interface for a basic mutex
type in glibc such that libgcc can use that instead?

Note that __deregister_frame, __register_frame and
__register_frame_table are present for backward compatibility only.
In principle they could be left out from the shared libgcc, which has
the additional advantage that this drops the dependency on malloc()
and free().  They're part glibc right now, but since they can be
easily implemented in terms of the new functions we can provide
an implementation in glibc for them.

new.o:
opdel.o:
opdelnt.o:
opnew.o:
opnewnt.o:
opvdel.o:
opvdelnt.o:
opvnew.o:
opvnewnt.o:
tinfo.o:
tinfo2.o:

These modules depend on the C++ ABI.  Should therefore not end up in
the shared libgcc.  Probably should be moved into a C++-specific
runtime library.

Re: What to put in a shared libgcc

[Geoff Keating]

> From: Mark Kettenis <kettenis@wins.uva.nl>
> Date: Tue, 11 Jul 2000 19:40:55 +0200

> I left out the arithmetic support functions (such as __ashldi3,
> __floatdixf, etc.).  These can go anywhere we like.  That probably
> means keeping them in the libgcc archive, provided we can address the
> problem of reexporting themfrom shared libraries created with GCC,
> which at least on Linux, I think we can.

Actually, it'd probably be better to put them in the shared library,
because they have very stable interfaces and because this solves the
reexport problem.

You can't just make all future shared libraries not export these
functions, because some existing shared libraries do export them and
you would break any applications linked to those libraries.  The
functions have to be around somewhere.

...
> frame.o:
...
> I'm a bit worried though about the fact that this program references
> pthreads functions.  This means that changing the ABI for these
> functions in libc might have disastrous consequences.  And since
> pthread_mutex_t isn't an opaque type, and might need to be extended to
> support new mutex attributes, changing the ABI may become necessary.
> Perhaps we should formalize an alternative interface for a basic mutex
> type in glibc such that libgcc can use that instead?

Note that the pthreads referencing depends on how gcc is configured.
A common trap on linux systems is to forget to build gcc with threads
enabled and then discover that the libc you build with your new gcc
doesn't work.

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: What to put in a shared libgcc

[Jeffrey A Law]

  In message < 200007111759.e6BHxfp26885@delius.kettenis.local >you write:
  > [Sorry folks, tried to send this to gcc@gnu.org instead of
  > gcc@gcc.gnu.org :-(]
  > 
  > Here's an analysis of the modules in libgcc.a for GCC 2.95.2 on
  > i586-pc-linux-gnu.  Feel free to put this up on the gcc web pages if
  > you like (linked to the libgcc.so discussion page or so).
  > 
  > Based on this analysis, I think the only stuff that should be moved
  > into a shared libgcc on Linux/x86 is the frame registration stuff
  > (frame.o) and probably parts of the language-independent exception
  > handling stuff (libgcc.2[L_eh], i.e. the stuff that ends up in _eh.o).
Actually, I *strongly* disagree with any notion that the contents of the
two libraries should be different.

Every major unix vendor has done this at some point in the last 10 years,
and every time it's caused problems.  Please, let's not make the same mistakes
everyone else did, instead let's learn from them.

The interfaces provided by the libraries need to be identical, anything
else just makes life a living hell for application developers as well as
tool developers.

Now I am open to the idea that there's libgcc.{a,so} that has some set
of routines and some other library that has additional routines.  However,
you have to be very careful about the things you do not include in libgcc --
for example the EH routines, which are the root of most of our recent
problems.

We can't do self-contained libraries that include copies of those routines,
it simply doesn't work.  Instead we need libraries which reference libgcc.so
(or whatever it's called) to get those routines.
jeff

Re: What to put in a shared libgcc

[Mark Kettenis]

   Date: Tue, 11 Jul 2000 17:12:35 -0600
   From: Jeffrey A Law <law@cygnus.com>

     In message < 200007111759.e6BHxfp26885@delius.kettenis.local >you write:
     > [Sorry folks, tried to send this to gcc@gnu.org instead of
     > gcc@gcc.gnu.org :-(]
     > 
     > Here's an analysis of the modules in libgcc.a for GCC 2.95.2 on
     > i586-pc-linux-gnu.  Feel free to put this up on the gcc web pages if
     > you like (linked to the libgcc.so discussion page or so).
     > 
     > Based on this analysis, I think the only stuff that should be moved
     > into a shared libgcc on Linux/x86 is the frame registration stuff
     > (frame.o) and probably parts of the language-independent exception
     > handling stuff (libgcc.2[L_eh], i.e. the stuff that ends up in _eh.o).
   Actually, I *strongly* disagree with any notion that the contents of the
   two libraries should be different.

   Every major unix vendor has done this at some point in the last 10
   years, and every time it's caused problems.  Please, let's not make
   the same mistakes everyone else did, instead let's learn from them.

   The interfaces provided by the libraries need to be identical,
   anything else just makes life a living hell for application
   developers as well as tool developers.

We've been doing it with glibc quite successfully.  A typical Linux
installation has

  /usr/lib/libc.a
  /usr/lib/libc_nonshared.a
  /usr/lib/libc.so
  /lib/libc.so.6

where /usr/lib/libc.so is the following linker script:

  /* GNU ld script
     Use the shared library, but some functions are only in
     the static library, so try that secondarily.  */
  GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a )

It works quite well (although from time to time someone manages to
replace the libc.so linker scrypt with a symlink to /lib/libc.so,
usually with the help of an old version of that braindamaged tool
called ldconfig).

Of course not all linkers support this nifty trick, and we can't force
evrybody to use GNU ld :-(.

   Now I am open to the idea that there's libgcc.{a,so} that has some
   set of routines and some other library that has additional
   routines.  However, you have to be very careful about the things
   you do not include in libgcc -- for example the EH routines, which
   are the root of most of our recent problems.

I'm not sure I understand what you're saying here.  Do you mean
libgcc.a or libgcc.so (or whatever it's called).  I'd say that you
should be very careful about what you *do* put in a shared library.
There are parts in the current libgcc.a for which it would be very
unwise to put them into the shared libgcc.so.  If you want the
contents of every lib*.so paralleled by a lib*.a, this would imply
that you'd put all functions that don't go into libgcc.so will be
moved to libgcc2.a (or whetever it'll be called).

   We can't do self-contained libraries that include copies of those routines,
   it simply doesn't work.  Instead we need libraries which reference libgcc.so
   (or whatever it's called) to get those routines.

Indeed.  The EH stuff is the minimal stuff that should go into the
shared library we're talking about in these discussions here.

Mark

Re: What to put in a shared libgcc

[Jeffrey A Law]

  In message < 200007112358.e6BNwfL30003@delius.kettenis.local >you write:
  > We've been doing it with glibc quite successfully.  A typical Linux
  > installation has
  > 
  >   /usr/lib/libc.a
  >   /usr/lib/libc_nonshared.a
  >   /usr/lib/libc.so
  >   /lib/libc.so.6
  > 
  > where /usr/lib/libc.so is the following linker script:
  > 
  >   /* GNU ld script
  >      Use the shared library, but some functions are only in
  >      the static library, so try that secondarily.  */
  >   GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a )
Interesting.  I wish other vendors's linkers had the same capability it
would have avoided quite a bit of pounding my head against the wall over
the years.

  > I'm not sure I understand what you're saying here.  Do you mean
  > libgcc.a or libgcc.so (or whatever it's called).  I'd say that you
  > should be very careful about what you *do* put in a shared library.
  > There are parts in the current libgcc.a for which it would be very
  > unwise to put them into the shared libgcc.so.  If you want the
  > contents of every lib*.so paralleled by a lib*.a, this would imply
  > that you'd put all functions that don't go into libgcc.so will be
  > moved to libgcc2.a (or whetever it'll be called).
What I was talking about was having two libraries -- one which would be
the intrinsics and EH support code (call it libgcc), the other would be
stuff that is far less version sensitive like profiling support (call it
libblah).

There would be no intersection between the functions provided by those
libraries.

Then again, it doesn't change the fundamental issue of dealing with the 
reexporting of the EH symbol problem.  But it does cut down on the number
things provided by libgcc for which we have to track ABI changes so
closely.

jeff