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

[Geoff Keating <geoffk at cygnus dot com>]

> Date: Tue, 11 Jul 2000 15:22:34 -0700 (PDT)
> From: Linus Torvalds <torvalds@transmeta.com>
> cc: gcc@gcc.gnu.org
> 
> 
> 
> On Tue, 11 Jul 2000, Geoff Keating wrote:
> > 
> > This is the routine that keeps track of all the exception-handling
> > information.  Consider a program that uses the standard C function
> > qsort, but the comparison function can detect an I/O error (it's
> > sorting pointers to on-disk data) and throw an exception back to the
> > application.  The exception throwing mechanism has to know how to
> > unwind the comparison function's stack frame and the qsort stack
> > frames and then find the handler in the application which can
> > deal with the error; in general, it needs to know about every bit of
> > code loaded into the process.
> 
> And this is in libgcc?

Yes.  It's support code for gcc.

> What about dload() and friends?

They (are supposed to) work.  The registration routines are called
from the dynamic object's initialisation routine.  This is not a
radical new design, many other systems use it.

> What about special loaders like the one XFree86 uses to re-use
> different object files across different systems?

If they want to make EH work, they have to run initialisation routines
too.  That's usually the least of their problems.  Usually people
doing such things deal with this issue by simply prohibiting exception
throwing inside or across such object files---I doubt the XFree86
people find this a problem.

> Sounds like a complete disaster to me.

It has worked well so far.

> Wouldn't it be better to _not_ consider this to be part of libgcc, and
> instead have a well-defined EH record format and just tell people to use
> it in their system libraries. Possibly with example code (ie the current
> libgcc source for the problem at hand).

There are already well-defined EH record formats for AIX, Solaris,
ia64, and Linux, and probably others.  It's just a shame that they're
all different, and gcc doesn't have the resources to support all of
them, and some of them don't work for gcc anyway because they were
designed without sufficient generality.

> Because I don't think libgcc can handle the special cases anyway (see
> above). And trying to is just going to cause problems.

It's one thing to try to handle every weird combination of user-loaded
code, shared libraries dlopened into static applications, and so on.
It's quite another to expect that in the usual case, of shared
libraries, dlopen()ed plug-ins, and normal C and C++ code, that
everything should work automatically.  This usual case already works,
it's just that we want more freedom than our current implementation
allows.

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