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

["H . J . Lu" <hjl at valinux dot com>]

On Mon, Jul 10, 2000 at 07:55:51PM +0200, Mark Kettenis wrote:
>    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.

It is too late now.

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

My libgcc runtime ABI is the first step to address all of your
concerns. The reason I choose "runtime.h" is a libgcc.so will be
built from libgcc.a. I'd like to have a header file to describe
the exported functions in libgcc.so. Most of the functions in
libgcc are internal to compiler. But the ones listed in "runtime.h"
are also used by glibc and collect2. In any case, the name of the
header file is not important here.

Once we define an exported ABI for libgcc, we can build a libgcc.so
knowing that any binaries linked with libgcc.so using the exported
ABI will work as long as libgcc.so conforms to the libgcc ABI.

I don't think gcc should build libgcc.so at all. It should be the
part of glibc or any system C libraries which use libgcc. When we
build glibc, we can do

# ld -shared -soname libgcc.so.3 \
	-o libgcc-`gcc -dumpversion`.so ... \
	--whole-archive `gcc -print-libgcc-file-name`

We can install libgcc-`gcc -dumpversion`.so under /lib and have
libgcc.so under /usr/lib. We can even make libgcc.so a linker
script:

---
GROUP ( /lib/libgccc.so.3 /usr/lib/libgcc_nonshared.a )
---

where /usr/lib/libgcc_nonshared.a contains the portion of basic support
functions in libgcc.a. We then link libgcc.so with libc.so instead of
libgcc.a. Now we have moved all the libgcc funtions from libc.so to
libgcc.so. I think we can make it to work.



-- 
H.J. Lu (hjl@gnu.org)