Re: A new libgcc symbol patch

[Zack Weinberg <zack at rabi dot columbia dot edu>]

On Sun, 13 Dec 1998 11:25:33 -0800 (PST), H.J. Lu wrote:
>> 
>> On Sun, 13 Dec 1998 09:22:01 -0800 (PST), H.J. Lu wrote:
>> >Hi,
>> >
>> >Here is my second libgcc symbol patch. My first one made too many
>> >libgcc functions local to the shared library. In this patch, I created
>> >the list of functions by hand. I hope I did it right this time.
>> [...]
>> >+LIBGCC_MAP_LIST=__ashldi3 __ashrdi3 __builtin_saveregs __clear_cache \
>> >+  __cmpdi2 __divdi3 __dummy __eprintf __ffsdi2 __fixdfdi __fixsfdi \
>> >+  __fixunsdfdi __fixunsdfsi __fixunssfdi __fixunssfsi __fixunsxfdi \
>> >+  __fixunsxfsi __fixxfdi __floatdidf __floatdisf __floatdixf \
>> >+  __gcc_bcmp __lshrdi3 __moddi3 __muldi3 __negdi2 __pure_virtual \
>> >+  __ucmpdi2 __udiv_w_sdiv __udivdi3 __udivmoddi4 __umoddi3
>> 
>> You left out the functions that were causing the problem in the first
>> place:
>> 
>>  __deregister_frame
>>  __deregister_frame_info
>>  __frame_state_for
>>  __register_frame
>>  __register_frame_info
>>  __register_frame_info_table
>>  __register_frame_table
>
>I left out them on purpose since there should be the exactly the one
>copy of them in the executable and in the shared liibraries. Think if
>we have
>
>__frame_state_for ()
>{
>  static int init = 0;
>
>  if (init)
>    return;
>
>  init = 1;
>  .....
>
>}
>
>It won't work if we have more than one copies. I only make those libgcc
>functions which I know can be safely made local in the shared library.

Fine, then the frame functions can't be in libgcc at all.

I think you still don't see the bug, or why it's a critical bug.  No
shared library can export ANY libgcc function, otherwise there is
binary incompatibility between the same shared library compiled by
different versions of gcc.  This is only acceptable for shared
libraries which are closely tied to the compiler, such as libstdc++.

>BTW, glibc 2.1 doesn't have any problem with it. Neither does the
>current glibc 2.0 in CVS.

You are mistaken.

Exercise:

- compile glibc (any version) with egcs (any version)
- compile it again with gcc 2.8
- compile a program with egcs and link it with the egcs-compiled libc
- attempt to run that program with dynamic linkage to the
gcc-2.8-compiled library.

This is *NOT* a hypothetical situation: it's what happens when you
compile a binary on (certain snapshots of a) Debian system, and try to
run it on a Redhat system.

Debian has dealt with the problem by reverting to gcc 2.7 for
glibc 2.0, but this will not work for 2.1, and they (sensibly) won't
touch gcc 2.8.

Ulrich's fix for the problem involves forcibly exporting the frame
functions from libc.  That works only as long as egcs is used to
compile libc (2.1) and the list of frame functions does not change.
We can't count on either.

>> It might be better to move *all* C++ specific support functions out of
>> libgcc into libstdc++, which is a shared library when possible.  I
>> think it's more likely that the semantics will be correct then.
>
>That is essentially the end result of my patch. I left out ALL
>C++ specific support functions from libgcc.map.

No, your patch means that C++ support functions will be in libstdc++,
and libc, and libm, and libX11, and everywhere else.  That is the same
situation we have now.  Your patch only fixes the problem for the
arithmetic support functions.

zw