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

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

   Date: Fri, 14 Jul 2000 12:44:29 -0700
   From: Geoff Keating <geoffk@cygnus.com>

   > Tightly controlling the libgcc.so ABI is extremely important.  The
   > SONAME of libgcc can *never* change (at least not without changing the
   > libc SONAME too) on Linux and the Hurd.  On the bright side these
   > systems use the complete GNU toolchain which means that we have a lot
   > more tools to avoid this than other platforms.

   Yes, this is required.  I think it's a good idea for other platforms
   too.

Sure :-).

   It doesn't require any special tools---to be precise, special tools
   don't help.

Well, we need the help from our tools on Linux to solve the the
problem with the frame functions living in glibc (versioning and
perhaps DT_AUXILIARY).

   For instance, symbol versioning is to solve the problem of how to have
   two functions named printf(), but this isn't needed for libgcc because
   if we (say) want to change the interface of _adddi3, then we can just
   call the new function _adddi3_2.

Which is so simple that it probably works for all platforms (although
you'd probably call it _adddi4 :-)).

   ...
   > And actually building a shared libgcc
   > *before* the GCC team is committed to mainting binary compatibility of
   > the stuff we're going to put into it is pointless.

   > Instead I'd like to start working with the GCC team on establishing an
   > ABI for that shared libgcc.  I could sure use some assistence on that
   > from GCC developers interested in Linux.

   The GCC team is already committed to binary compatibility with older
   versions of gcc, like 2.95.2, so we could start with that.  In fact,
   we have to start with that.

I'm afraid gcc 2.8 and the various egcs releases will have to be taken
into account, at least for various x86 targets, and at least for plain
C.  A lot of C++ devlopers still use egcs 1.1.2 since allegedly gcc
2.95.2 tends to produce too many ICE's.

Linking with older object files and static libraries isn't essential,
but interaction with shared libraries is.  But I think that's doable,
it just takes some time to do some field testing, the problem being
that stuff on development machines tends to be recompiled too often,
making it hard to find old libraries.

   Now, what else would we like?  As a starting point, I think that if
   we're going to change the frame.o ABI, we should change it to
   something more future-proof.  Or do we want to export the eh.o ABI?
   In that case we'd better wait for the new C++ ABI, too.

The frame.o (now mostly frame-dwarf2.o I guess) and
eh.o modules are coupled via __frame_state_for().  The problems that
more or less started this thread suggest that __frame_state_for() was
(accidently) regarded as an internal interface.  In that case the
frame.o and eh.o modules have to match, and the EH ABI would have to
be fixed as well.

Mark