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: thorpej at zembu dot com
- Subject: Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)
- From: Richard Earnshaw <rearnsha at arm dot com>
- Date: Fri, 14 Jul 2000 17:46:22 +0100
- Cc: Alexandre Oliva <aoliva at redhat dot com>, "H . J . Lu" <hjl at valinux dot com>, Ulrich Drepper <drepper at cygnus dot com>, law at cygnus dot com, Mark Kettenis <kettenis at wins dot uva dot nl>, rth at twiddle dot net, libc-hacker at sourceware dot cygnus dot com, gcc at gcc dot gnu dot org
- Cc: rearnsha at arm dot com
- Organization: ARM Ltd.
- Reply-To: rearnsha at arm dot com
> On Fri, Jul 14, 2000 at 03:21:32PM +0100, Richard Earnshaw wrote:
>
> > This isn't quite true. We don't install a shared libgcc on BSD platforms
> > because libc has replacements for the most common libgcc functions built
> > into it. This is an equally disgusting hack because it assumes that the
> > definitions in there will be sufficient even if the compiler is upgraded.
> > I suspect it will cause even more problems moving forward when we need to
> > include exception management support.
>
> Err, which functions, specifically? If you're talking about stuff
> like __ashlsi3, the m68k ports have that stuff in libc mostly as
> an historical accident (Utah put them in there in the HP-BSD days,
> and they were just never really removed, even though libgcc has those
> functions as well).
>
> ...or are you referring to something else?
>
> (Serious question ... if I am misunderstanding this, I would like to
> understand it better...)
>
Yes. They are still there. And because of the way shared libs work I
believe they have to be. Consider something like __divsi3 and then assume
that it isn't in libc.so and that we don't have a shared libgcc. There
are two ways the linker could work:
1) The linker doesn't resolve symbols from shared libs into archives: If
it is needed by libc.so and it weren't needed by the application the
linker wouldn't put it into the application. So we would get a run-time
fault when the symbol isn't found.
2) The linker does resolve symbols from shared libs into archives: this
would result in every symbol possibly needed by libc from libgcc getting
put into the static part of the application even if it weren't needed for
that application (the linker can't pick apart the dependencies of the
shared lib). This leads to code bloat since now we include __divsi3 in
our app even if we never call it.
Now I think about it, I can't hand-on-heart say which is the way it really
happens: I think it is the first; and even if it isn't the consequences
aren't pretty.
R.