This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
libgcc_s, Linux, and PT_GNU_EH_FRAME
- From: "Martin v. Loewis" <martin at v dot loewis dot de>
- To: gcc at gcc dot gnu dot org
- Date: Mon, 5 Aug 2002 06:23:39 +0200
- Subject: libgcc_s, Linux, and PT_GNU_EH_FRAME
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.
B) The ABI mandates that crtstuff dynamically supports both
approaches. Presence of a symbol in libgcc_s would indicate that
PT_GNU_EH_FRAME is supported, and thus __register_frame_info_bases
calls are not needed. Absence of this symbol would indicate that
registration is required (even if later the PT_GNU_EH_FRAME
technique is used).
Notice that the C++ ABI is silent on this issue, since it specifies
only the Itanium psABI; this uses Itanium unwind descriptors instead
of DWARF2.
HTH,
Martin