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.)
- To: hjl at valinux dot com
- Subject: Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)
- From: Mark Kettenis <kettenis at wins dot uva dot nl>
- Date: Tue, 11 Jul 2000 19:36:37 +0200
- CC: law at cygnus dot com, drepper at cygnus dot com, rth at twiddle dot net, libc-hacker at sourceware dot cygnus dot com, gcc at gcc dot gnu dot org
- References: <m3bt04k58c.fsf@otr.mynet.cygnus.com> <5003.963333245@upchuck> <20000711100049.A15651@valinux.com>
Date: Tue, 11 Jul 2000 10:00:49 -0700
From: "H . J . Lu" <hjl@valinux.com>
I don't think Linux has much choice. It probably has to be installed
along side with libc.so.
It also might have to be installed whenever a new version of GCC is
installed. In fact that's the only moment a new libgcc.so will have
to be installed apart from bootstrapping the whole scheme.
> >
> > > what version # to use for libgcc,
> >
> > This implies you are willing to track the version numbers for all the
> > different target. Again, my argument is that you are *not* able to do
> > this accurately since you cannot effort spending that much time on it.
> But we need to -- we're not just building a linux compiler. We need this
Look it this way. Since gcc is not a linux specific compiler and
the libgcc/libc issuse is limited to very few targets, why should
gcc spend HUGE amount of time up front and for continuing support?
In essence, the issues aren't really a libgcc/libc issue. Currently
all ELF systems have similar problems with getting exceptions working
in the presence of shared libraries. Most of the other systems with
shared libraries probably suffer too.
The fact that the Linux libc contains and reexports the frame info
registration functions make things a little more complicated, and
might induce the need for some additional tweaks. But the problem
isn't Linux-specific by far.
Mark