Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

["H . J . Lu" <hjl at lucon dot org>]

On Tue, Jul 18, 2000 at 06:20:38PM +0200, Mark Kettenis wrote:
> 
>    I am doing some experiments on the shared libgcc. I have added
>    -Wl,--auxiliary,libgcc.so.3 when building my libc.so. I created a
>    shell script, updatelibgcc. updatelibgcc takes CC and slibdir from
>    environment to build/install libgcc.so.3. It seems to work so far.
> 
>    One interesting thing I noticed that libgcc.so might not be needed
>    at all under Linux. I don't like the explicit dependency on libgcc.so.
>    Can someone tell me if there is a case --auxiliary libgcc.so.3 is not
>    enough for Linux? I may have missed something.
> 
> Let me refresh your mind:
> 
>  1. We have __deregister_frame_info, __register_frame_info,
>     __frame_state_for, etc. in libc.so.
> 
>  2. A single copy of these functions must be used in every program.
> 
>  3. It might be necessary to change the implementation (while
>     maintaining backwards compatibility) of these functions to support
>     new versions of GCC.  This implies that the single copy mentioned
>     above must be the most recent copy.
> 
>  4. We don't want to force everybody to recompile or even upgrade libc
>     whenever they install a new version of GCC.
> 
> The only reliable solution that has been found thus far is putting
> these functions in a shared library that can be upgraded (in principle
> when installing a new version of GCC) whenever needed.

Guess what, that shared library has been there for a long time. It is
called libstdc++.so. Why do we need libgcc.so when libstdc++.so is
there? I noticed the problem with the shared libstdc++ v3. But I
found out it was caused by libtool:

http://gcc.gnu.org/ml/gcc-patches/2000-07/msg00707.html

You may ask what if I don't use the shared libstdc++. It is fine since 
you are using static EH functions in libgcc as far as libgcc is
concerned since those EH functions are pulled in from libgcc.a by the
linker.

Currently, glibc doesn't use exceptions. As long as the ABI of those
frame functions are unchanged, glibc should be ok. Right now, only
ia64 is broken due to the new fields in "struct object". My suggestions
for glibc are:

1. Fix "struct object" in elf/soinit.c. A glibc ABI will be nice.
2. Fix libtool and shared libstdc++ v3 so that we can use it as the
shared library for thos EH functions.

We can take another look at the shared libgcc issue when the EH is used
in glibc. We will make a decision then. I don't think we need it now.



H.J.