libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Martin v. Loewis]

Mark Mitchell <mark@codesourcery.com> writes:

> >> I agree.  I don't think we need to do this for GCC 3.2, but I do think
> >> it would be good to do this at some point.
> >
> > If you don't do this for 3.2, you will definitely end up with two
> > incompatible ABIs on Linux, both of them in wide use.
> 
> Walk me through it, if you please.
> 
> How will this happen?

The elaborate walkthrough is in

http://gcc.gnu.org/ml/gcc/2002-08/msg00192.html

Here is the short version: Linuxes fall in two categories:

- those that have glibc 2.2.5 or better, and binutils 2.12.1 or better
  (type A)
- those that miss either the latest binutils, or the latest glibc
  (type B)

Type A systems use unwind-dw2-fde-glibc in libgcc_s, and do not invoke
__register_frame_info_bases in crtstuff. Type B systems use unwind-dw2-fde,
and do invoke __register_frame_info_bases.

If a program or DSO that catches an exception is compiled on a type A
system, this program will std::terminate on a type B system, since
_Unwind_Find_FDE will fail to find the frame info. 

So, binaries compiled on type A systems have an ABI not supported on
type B systems. Compatibility in the other direction is supported.

Unfortunately, all Linux distributions shipped today are type B
systems (with the exception of Debian 3.0). So anybody building gcc
3.2 on a current Linux system will get a type B ABI.

All future releases of Linux will be type A systems, as they surely
use latest binutils and glibc (unless a vendor isn't aware of the
issues, and fails to use the latest stuff with gcc 3.2).

Users of type B systems will find that binaries abort that work fine
on other systems, with no indication of an error.

Does this make the problem clear?

Regards,
Martin