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

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

   Date: Mon, 10 Jul 2000 08:03:57 -0700
   From: "H . J . Lu" <hjl@valinux.com>

   I haven't heard any feedbacks about my proposal for the libgcc runtime
   ABI:

   http://gcc.gnu.org/ml/gcc-bugs/2000-07/msg00117.html

   But I think the current situation is quite broken.

Indeed it is.  And apparently people aren't very eager to do something
about it.  The fact that your "proposal" isn't really shocking might
have something to do with it.  Let me explain.  The ABI you're
proposing does already exist.  Changing `sizeof (struct object)' or
changing the calling convention of the functions mentioned in your
runtime.h isn't possible anymore for supported targets with working
exception support in gcc 2.95 or egcs 1.0.3 or so (and has indeed been
impossible for quite a while now for some of those targets).  So
you're either just trying to formalize things, which is fine with me,
or you're proposing something that cannot be done.

Adding a new ABI without continued support for the old one isn't
possible either unless you want to force people to recompile
everything with the new gcc.

On Linux (and the Hurd) the problem is even worse.  Since the frame
info registration functions are present in libc.so, you cannot simply
add a new ABI without forcing everybody to patch and recompile libc.
If we plan ahead it is certainly possible to ease the pain
considerably, but this requires a lot of cooperation between the glibc
and GCC teams, and depending on the solution that's chosen, probably
quite a bit of time (in the order of months).  If this isn't done,
deploying GCC 3.0 on Linux will become a terrible nightmare.

I'm having some problems with "libgcc runtime ABI".  Right now libgcc
is a pile of junk that contains some basic support functions (e.g. for
long long and floating point arithmetic), the exception handling stuff
(both registration of EH frame info, and the language independent EH
runtime stuff), and some sort of C++ runtime (operator new, rtti,
etc.).  Your proposal is at best a specification of the "libgcc EH
frame info registration ABI".

In that respect, the name "runtime.h" seems not very appropriate to
me.

Mark