This is the mail archive of the gcc@gcc.gnu.org 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 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


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