This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 are circulating on
Linux: One that uses unwind-dw2-fde.c, and one that uses

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
(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 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 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]