Re: Problems with exception handling in glibc and gcc.

[Mark Kettenis <kettenis at wins dot uva dot nl>]

   Date: Tue, 4 Jul 2000 02:52:02 -0700
   From: Geoff Keating <geoffk@cygnus.com>

   > From: Jason Merrill <jason@redhat.com>
   > Date: 04 Jul 2000 04:03:56 -0400
   > 
   > Geoff Keating <geoffk@cygnus.com> writes:
   > 
   > > > We should have learned the lesson when last time we did it in Dec.
   > > > 1997. We had a lengthy discussion then. I am not sure if any messages
   > > 
   > > It's happened several times since.  It's quite annoying.  Perhaps we
   > > could put a comment in there to stop this happening?
   > 
   > No.  These interfaces are internal to libgcc and should not be
   > restricted.  The proper fix is to stop exporting these functions from
   > glibc.  There's no reason to do that.  Really, there's no reason for

Some of the interfaces aren't internal to libgcc.
__register_frame_info, __deregister_frame_info and `struct object' are
used by crtstuff.c (i.e. crtbegin.o and crtend.o).  You cannot change
their ABI since on systems with shared libraries it will happen that a
crtbegin.o from an older compiler will be used together with a libgcc
from a new compiler.

   If we don't export the functions from glibc, how do applications gain
   access to glibc's EH frame information?  There are a number of glibc
   functions that are supposed to support throwing exceptions (from user
   procedures passed to them), like qsort and tsearch.

By doing the same trick as GCC's crtstuff.c does (IIRC since egcs
1.0.3).  Have a weak reference to __register_frame_info, and call it
if its non-NULL (i.e. if the program picked up a copy of those
functions because it actually *uses* the EH frame info).

   This is not a sudden new restriction.  As HJ mentioned, it has been
   around since at least 1997.  In fact, I proposed that we put a comment
   in frame.h one of the last times this happened, I think in late 1999.
   "Those who do not remember history..."

Indeed.  And over the past few years, we've been applying stopgap
after stopgap to solve these problems.  We should stop doing that
right now, and plan ahead instead.  This requires some cooperation
between GCC and the glibc project.  IMHO both glibc 2.2 and GCC 3.0
should not be released before we have a proper solution that has been
verified to work.  This might very well include turning parts of
libgcc into a shared library.

   The proposed libgcc shared library would help somewhat.  It would mean
   that this interface is internal (of course backwards compatibility
   functions using the old version of the structure would need to be
   provided), but it doesn't mean things can be changed at random; in
   fact, it may be worse than the current situation because it means the
   __throw ABI must stay fixed.

Blindly turning libgcc into a shared library wouldn't be very wise.  I
share Geoff's worries about it, especially if libc.so is somehow tied
to libgcc.so.

   > them to be in glibc at all, but at the very least they should be
   > hidden.
   > 
   > I don't suppose there's any way to suppress them in currently
   > installed glibcs?

   No.  In fact, we can't take them out of glibc now, because not all
   programs contain a copy of them and so taking them out of glibc would
   cause those programs to stop working.

But it might be possible to prevent new programs from linking against
the versions in glibc, such that they won't ever use the copies in
glibc again.  However, doing so only makes sense if GCC and the rest
of the toolchain make sure that a single copy of the frame info
functions is used.

Mark