Re: DWARF EH for PPC

[hjl@lucon.org (H.J. Lu)]

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

Could you please tell me which files in CVS are changed as well as the
ChangeLog entries? I didn't see anything in CVS on the 2.0 branch.

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

That won't happen on ELF with my patch to crtstuff.c

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

I didn't see it in libc.so in the current glibc 2.0. The problem is
with libm.so, which does export those frame functions and libstdc++
is linked with -lm.

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

All those problems should be solved with my library versioning patch,
which is in the egcs main trunk. It is too bad that it is not in egcs
1.1.1. However, I do have a patch for egcs 1.1.1.


H.J.