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

[Geoff Keating <geoffk at cygnus dot com>]

> Mailing-List: contact libc-hacker-help@sourceware.cygnus.com; run by ezmlm
> Date: Fri, 14 Jul 2000 16:25:05 +0200
> From: Mark Kettenis <kettenis@wins.uva.nl>

[aoliva said:]
>    Now think of glibc: since it uses libgcc, it will also have some
>    particular libgcc SONAME encoded in it.  But libgcc already depended
>    on libc, so we have a circularity.  No big deal: each library will
>    only be loaded once, and everything is fine, right?  Despite the minor
>    problem of how to bootstrap this situation.

You can have circular dependencies involving libc.  libc is not needed at
program startup, ld.so includes everything it needs (it has to, since
it's responsible for loading libc anyway).

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

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

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.

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

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.

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