This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)
Date: Mon, 10 Jul 2000 15:34:40 -0700
From: Richard Henderson <rth@twiddle.net>
On Mon, Jul 10, 2000 at 11:44:52AM -0700, H . J . Lu wrote:
> 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.
I disagree entirely.
It's certainly the GCC people who should control the libgcc.so ABI.
And since a libgcc.so upgrade may be necessary when a new compiler is
release, it's probably GCC that should install it. By all means it
should be a "servicable component"; something you can upgrade without
the need for upgrading all system C libraries with it.
I think libgcc should be its own thing and its own thing alone.
We need to get glibc out of the business of providing libgcc
functions. The best long-term way to do that, IMO, is once
libgcc.so exists, have libc.so reference it as DT_AUXILIARY.
That will provide for all backward compatibility wrt the symbols
glibc currently exports.
The key word here is "long-term". Until we are in the situation you
describe any significant changes to the frame info registration
interface will cause serious binary compatibility problems on Linux.
By the time of the next major GCC release ships (presumably with the
frame registration functions in a shared library that's installed in
/lib on most systems), we should have verified that something like the
DT_AUXILIARY thing indeed works. You cannot say two months before the
GCC 3.0 release "oh yeah, we were going to turn libgcc into a shared
library, let's do it now" and expect things to work right away.
Therefore planning on what to put in libgcc.so should start ASAP.
Mark