Re: DWARF EH for PPC

[Zack Weinberg <zack@rabi.columbia.edu>]

On Tue, 8 Dec 1998 19:31:08 -0800 (PST), H.J. Lu wrote:
>
>I am not suggesting anything. I got different rerults on glibc 2.0
>than Debian since Debian uses some glibc 2.1 patches on glibc 2.0.
>That is all. I was trying to explain why those frame functionas were
>in my libstdc++.so under my glibc 2.0.

Since I wrote the patch you're talking about, perhaps I should explain
what's actually going on here.

The patch I wrote was intended for the 2.0 branch, and as far as I
know has been added to the 2.0 branch.  It papers over what's
fundamentally a compiler bug.  In 2.1 we can use symbol versions to do
a better job of papering it over, but the bug is still there.

The bug is a subtle interaction between the way EGCS (all versions)
implements exception handling, and the way shared libraries are
constructed.

EGCS' exception handling uses a bunch of internal library functions.
They are in libgcc.a.  Those functions are referenced from every
translation unit compiled without -fno-exceptions, whether or not it
has exceptions in it.  gcc 2.7/2.8 does not have these functions in
its libgcc.a, and doesn't refer to them in programs it compiles.

When libc is built, it is linked with libgcc.  We have to do that
because libc may need libgcc functions that some executable that uses
it doesn't need.  The 2.0 libc then turns around and re-exports all
the libgcc functions that it pulled in.  If 2.0 libc is compiled by
egcs, that includes the exception handling functions.  In 2.1 we can
prevent this but we've chosen not to; see below for why.

When executables are built, gcc links first with libgcc, second with
libc.  The executable gets static copies of the exception functions,
and all is well.

When other shared libraries are built, they are linked first with 
libc and second with libgcc.  That means they don't get static copies
of the eh functions; they refer to the ones in libc.  That
reference will only be satisfied at runtime if the libc.so in use then
was compiled by egcs.

My patch for 2.0 changed the link ordering for extra-libs provided by
libc, so that they would get their own static copy of the eh
functions.  Now there is no dependency of libm (for example) on an
egcs-compiled libc.  But this only shifts the problem, because if you
give gcc any -l options, it links with those before it links with
libgcc.  Therefore the executable will want the eh functions to be in
libm.  That will only be true at runtime if the libm.so in use then
was compiled by egcs.

In 2.1, we can ensure that all our shared libraries have version maps
that don't export the eh functions.  That doesn't fix the general
problem, because most shared libraries are not provided by glibc.  A
program linked with libX11-compiled-by-egcs will have a dependency
which is not satisfied by libX11-compiled-by-gcc-2.8.  Instead, Ulrich
has chosen to explicitly export the eh functions from libc.  That
means they are part of the official 2.1 ABI, and everyone is supposed
to reference our copy and not the one in libgcc.  This works as long
as libc 2.1 is always compiled by egcs.  If it is ever compiled by gcc
2.8, it will be binary incompatible with the version compiled by egcs.

The right fix to the problem is to change gcc such that libgcc is
always linked ahead of all libraries specified on the command line -
i.e. if I write

gcc -o prog prog.o -lfoo -lbar

the linker command line must wind up like this:

ld -o prog crt1.o ... prog.o -lgcc -lfoo -lbar -lc -lgcc ... crtn.o

and similarly when shared libraries are linked (using gcc -shared).
Then everyone will get a private copy of the eh functions and the
problem will not arise.

Until this is done, the right thing to do is:

never compile glibc 2.0 with egcs
always compile glibc 2.1 with egcs.

zw