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

[Richard Henderson <rth at cygnus dot com>]

On Wed, Jul 12, 2000 at 01:30:47PM -0700, Linus Torvalds wrote:
> If the format is well-defined, then you should consider this to be a
> loader and systems thing, not a gcc thing. Why are the routines in libgcc
> at all? Why aren't they in the loaders, or the libraries?

This is just passing the buck, and does no one any good.

Look: it's not a loader thing, because the loader is and has been doing
exactly what it was designed to do.  Namely, map binaries in memory and
resolve symbols.

It is a library thing, but there's no standard library to defer to.  What
library do we have control of under Solaris except libgcc?  Quite a lot
of the system vendors have their own special hacky way to do exception
handling, and most of them suck.  We're using dwarf2 (almost) across the
board, and that, with the exception of Irix, means we'd have to write our
own code to handle the unwinding, etc.

Further, even under Linux we don't want to pawn this off even on glibc. 
(Ignoring the fact that I don't think Linux should be an exception for the
GCC team managing the EH routines.)  The scenario is that someone's got
last year's glibc installed, which has all the EH routines they need. 
Along comes P3 and SSE which requires us to enforce stack alignment,
which requires masking the incoming stack pointer and other such ugliness,
which requires emitting new sorts of unwind directives that the old EH
routines were never designed to handle.  Which means that our hapless user
has to wait for and upgrade to the next glibc release in order to use this
new gcc feature.  As opposed to having gcc provide an update to the shared
library that handles exception handling.

> I think it was Kenner who said that libgcc should only contain code that
> is actually called by gcc-generated code. That's a good definition of what
> libgcc used to be.

And still is.  GCC does generate calls to the EH routines.  We generate
calls to the EH registration routines at startup, and we generate calls
to the EH dispatch routines at runtime.

How else do you think `throw new int(8);' happens?

There's no point in this thread going further.  There is exactly zero
chance that the GCC team will not manage GCC exception handling routines.
It will not be spun off to a self-contained package, and Linux will not
be special cased wrt deferring to "system libraries", i.e. glibc.


r~