libgcc_s, Linux, and PT_GNU_EH_FRAME

[Jakub Jelinek]

On Mon, Aug 05, 2002 at 06:23:39AM +0200, Martin v. Loewis wrote:
> I recently debugged a problem where moving a binary from one gcc 3
> installation to another would fail. The symptom was that an exception
> could not be caught, with __cxa_throw invoking terminate in
> 
>  // Some sort of unwinding error.  Note that terminate is a handler.
>   __cxa_begin_catch (&header->unwindHeader);
>   std::terminate ();
> 
> Since others appear to have run into the same problem, I thought I'd
> share my analysis.
> 
> The problem is that two versions of libgcc_s.so.1 are circulating on
> Linux: One that uses unwind-dw2-fde.c, and one that uses
> unwind-dw2-fde-glibc.c.
> 
> The former uses a registry of frame infos maintained in libgcc_s; the
> latter uses lazy lookup through dl_iterate_phdr of the PT_GNU_EH_FRAME
> headers (a feature that is only available in recent glibc 2.2).
> 
> Now, if you compile a binary configured for the latter approach, it
> won't invoke __register_frame_info_bases in its crtbegin. If you
> execute such a binary on a system using the former libgcc_s.so.1
> (specifically, the _Unwind_Find_FDE function that libgcc_s provides),
> no FDE can be found since the executable/DSO has not been registered.
> 
> I don't know whether the libgcc_s.so.1 copies were just "old" in all
> cases where they cause problems. However, for compatibility across
> Linux distributions, it seems essential that either
> 
> A) The ABI mandates that one specific approach for finding frame infos
>    is used. Mandating support for PT_GNU_EH_FRAME is probably more
>    efficient, but also requires a recent libc.so.6 binary.

I think it is best just to say in the docs that 3.2 linux ABI compatibility
requires: binutils 2.12.1+, glibc 2.2.5+ used when configuring and
configuring with --enable-threads=posix --enable-shared --enable-__cxa_atexit
(dunno if other configure options matter for binary compatibility).
Slowing crtstuff forever just because somebody when upgrading gcc cannot
upgrade glibc and binutils first doesn't look like a good thing to me.
You really need recent binutils for working .hidden anyway (so that
libgcc.a is all hidden) and recent glibc e.g. for the __cxa_atexit stuff.

	Jakub