Re: DWARF EH for PPC

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

On Wed, 9 Dec 1998 07:07:36 -0800 (PST), H.J. Lu wrote:
>> 
>> 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.

Correction - it doesn't seem to have gone into 2.0, but Debian took
it.

The change was to take all the explicit dependencies on libc.so out of
the subdir Makefiles.  Due to the way $(build-shlib) is put together,
this has the effect of linking extra-libs with libgcc.a before
libc.so.  I no longer think this does any good at all.

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

Which patch to crtstuff.c is that?  I still had the problem with
snapshot egcs as of a couple days ago.

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

Please check again.  The scenario I had was definitely that libc
exported the frame functions and libm, libstdc++, etc. had undefined
references.  You may have thought that libc itself was OK because egcs
always links libgcc before libc, so the problem is masked for any
executable that only needs libc.

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

I don't think library versioning will help here.  That just prevents
you from mixing up libstdc++ compiled by gcc with libstdc++ compiled
by egcs.  The bug Debian sees affects _every_ shared library - C or
C++ - compiled by egcs.

zw