Re: Problems with exception handling in glibc and gcc.

[Geoff Keating <geoffk at cygnus dot com>]

> Cc: hjl@lucon.org, drepper@cygnus.com, amacleod@cygnus.com,
>         libc-alpha@sourceware.cygnus.com, gcc-bugs@gcc.gnu.org,
>         jason@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

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.

It's not helpful to suggest that glibc should instead export its dwarf
EH tables.  Consider the last change to the EH mechanism, for
instance; it adds a new dwarf opcode, so if there was a glibc built
with this new compiler it would fail to work with old applications
linked with a libgcc which doesn't understand the new opcode.

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..."

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.

> 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.

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