Re: [PATCH] Updated glibc-gcc3.patch

[Jakub Jelinek <jakub at redhat dot com>]

On Thu, Nov 15, 2001 at 05:39:57PM -0800, Ulrich Drepper wrote:
> As you can see, I've applied the patch now.  But I changed quite a bit
> before that.  No file should be added if the minimum ABI is 2.2.5 or
> later.  I don't see why a strange version name like GCC_3.0 should be
> used so that is changed as well.  Also, the configure code must assume
> that by default the compatibilty stuff is not needed; platforms must
> explicitly enable it.

But is the __*register_frame* and _Unwind_Find_FDE in glibc really just
compatibility stuff?
__frame_state_for definitely is, but the *register_frame* routines will be
used by gcc 3.0.x, 3.1.x and later too. And when they are available in
glibc, all C shared libs can be built with -static-libgcc (actually it could
be the default for those glibc 2.2.5+ platforms, ATM I'm using such patch in
our gcc 3.1 rpm). C shared libs don't need the frame unwinding stuff in
libgcc_s.so, they just want to register their potential .eh_frame section.
Also, when you changed the symbol versions from GCC_3.0 to GLIBC_2.2.5, it
means binary compatibility is lost.
Say on x86, if you have some pre-gcc3.0 compiled shared lib C with some
-fexception stuff, they will register using __register_frame_info@GLIBC_2.0
(lets assume the main program is C only, not linked against libgcc_s.so,
thus they will register with glibc). When this dlopens a C++ library which
calls _Unwind_Find_FDE@GCC_3.0, it will obviously not able to throw through
that lib, since _Unwind_Find_FDE@GCC_3.0 will be found only in libgcc_s.so
(and it registered with glibc, but _Unwind_Find_FDE@GLIBC_2.2.5 will be
totally unused).

	Jakub