Re: Problems with exception handling in glibc and gcc.

["H . J . Lu" <hjl at lucon dot org>]

On Tue, Jul 04, 2000 at 02:47:53PM -0700, Geoff Keating wrote:
> 
> >    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
> 
> This is an incredibly good idea.
> 

The problem is there should be only one copy of the exception funtions
used in the main executable and all DSOs. If we decide that glibc 
will never use the exception, things may be a little easier. We can
somehow stop including the new exception ABI functions in glibc while
keeping the old exception ABI functions for existing binaries. We also
make sure the main executable always exports the the new exception ABI
functions if they are used. But I don't know if we can live with such
a limitation.

If we want the exception support in glibc, I can see 3 choices:

1. Link the exception functions into the shared glibc, which is what we
have today.
2. Always link the exception functions into the main executabele so
that the shared glibc can use them.
3. Make libgcc.so shared so that everyone can share it.

Eevery choice has its pro/con. 3 is kind of attractive to me. But
we have to be very careful about. Otherwise, we may be in a bigger
trouble in the future. I'd like to see libgcc.so has a well defined
ABI and a carefully chosen installation location.


H.J.