[Dwarf-discuss] Duplicate frames?

Thu Jul 27 20:01:09 GMT 2006

On Thu, Jul 27, 2006 at 03:08:42PM -0400, Steve O'Neill wrote:
> Hello,
> 
> I am working on an application which uses libdwarf to extract symbol 
> information from executable images.  A problem that I have seen lately 
> is that when analyzing some images I get a DW_DLE_DEBUG_FRAME_DUPLICATE 
> error message followed by an immediate exit.
> 
> Experimenting with this a bit I've found that for the most part these 
> problem applications contain a .eh_frame as well as a .debug_frame.  In 
> some cases I find an .eh_frame and two .debug_frames.  I've also found 
> through experimentation that, although most likely a Bad Thing, by 
> simply ignoring the error and continuing on I am able to achieve the 
> results that I need.
> 
> Is there anywhere that I can get some background on
> 1) what the eh_frame is and why it can't co-exist with a debug frame?
> 2) how and why am I seeing multiple debug frames?
> 3) is there a linker option that can avoid the multiple frame problem?
> 
> Any information and/or pointers would be appreciated.  Note - I am 
> working with the 20060614 release of libdwarf on an Octane2 running Irix 
> 6.5.23.
> 

There should be no problem with .eh_frame & .debug_frame coexisting.  We have
compilers that produce both, and tools that interpret either depending on
what's available in the executable.  Having two .debug_frame's in a single
executable or shared library is pretty strange, though.

I've never found any comprehensive document describing .eh_frame.  You'll
find some text in the AMD64 ABI: http://www.x86-64.org/documentation/abi.pdf.

And here's what I've learned by hook or by crook while writing .eh_frame
emitters and consumers.  It's pretty close to being a .debug_frame section,
except that it should be loaded into the executing address space (where
.debug_frame rarely or never is), and it has these differences:

 * In .eh_frame, for a CIE, the CIE_id that identifies it as such is -1
   instead of 0.
 * In .eh_frame, for an FDE, the CIE_pointer is relative to a location in the
   FDE (I think specifically to the address of the CIE_pointer itself, but
   you'd do well to do a sanity check on that).
 * In a shared library, in .eh_frame, addresses are relocated so that you
   don't need to add any base address.

Finally, .eh_frame uses a bunch of augmentation strings beyond what you'd
find in a .debug_frame section.  Here are a couple archived gcc mailing list
emails that describe them in more detail:

--------------------------------------------------------------------------------
http://gcc.gnu.org/ml/gcc/2003-12/msg00961.html
--------------------------------------------------------------------------------

Re: documentation for augmentations in .eh_frame?

    * From: Richard Henderson <rth at redhat dot com>
    * To: davidm at hpl dot hp dot com
    * Cc: gcc at gcc dot gnu dot org
    * Date: Tue, 16 Dec 2003 13:49:06 -0800
    * Subject: Re: documentation for augmentations in .eh_frame?
    * References: <200312160159.hBG1x9d4007312 at napali.hpl.hp.com>

On Mon, Dec 15, 2003 at 05:59:09PM -0800, David Mosberger wrote:
> Is there any documentation (other than the source-code) that describes
> the augmentations used in the .eh_frame section?

No.  I meant to do something more formal but never got around to it.
The source code block comment in dwarf2out.c: 

      /* Augmentation:
         z      Indicates that a uleb128 is present to size the
                augmentation section.
         L      Indicates the encoding (and thus presence) of
                an LSDA pointer in the FDE augmentation.
         R      Indicates a non-default pointer encoding for
                FDE code pointers.
         P      Indicates the presence of an encoding + language
                personality routine in the CIE augmentation.  */

should be mostly clear.  As for the encodings themselves, the bits
are defined at the end of dwarf2.h.  Again the meanings should be
moderately self-explanitory, especially if combined with the code
in unwind-pe.h that decodes them.

> A related question: it appears to me that the "text base" (tbase) in
> the DWARF2 unwinder could only ever be non-zero if
> __register_frame_info() gets called (which, I believe won't be the
> case on "modern" systems).  Is this correct?

No.  See _Unwind_IteratePhdrCallback in unwind-dw2-fde-glibc.c.
There is currently target-specific code in there to get dbase
set for i386.  If tbase is ever needed for a different port then
we'll add a similar bits for that.  Indeed, there is a port within
Red Hat that might start using tbase with SEGREL type relocs.

r~

--------------------------------------------------------------------------------
http://gcc.gnu.org/ml/gcc/2003-12/msg01168.html
--------------------------------------------------------------------------------
Re: documentation for augmentations in .eh_frame?

    * From: David Mosberger <davidm at napali dot hpl dot hp dot com>
    * To: Richard Henderson <rth at redhat dot com>
    * Cc: davidm at hpl dot hp dot com, gcc at gcc dot gnu dot org
    * Date: Fri, 19 Dec 2003 11:33:20 -0800
    * Subject: Re: documentation for augmentations in .eh_frame?
    * References: <200312160159.hBG1x9d4007312 at napali.hpl.hp.com><20031216214906.GA31351 at redhat.com>
    * Reply-to: davidm at hpl dot hp dot com

>>>>> On Tue, 16 Dec 2003 13:49:06 -0800, Richard Henderson <rth at redhat.com> said:

  Richard> On Mon, Dec 15, 2003 at 05:59:09PM -0800, David Mosberger
  Richard> wrote:

  >> Is there any documentation (other than the source-code) that
  >> describes the augmentations used in the .eh_frame section?

  Richard> No.  I meant to do something more formal but never got
  Richard> around to it.  The source code block comment in
  Richard> dwarf2out.c:

Below is what I wrote up while trying to understand what the heck
those augmentations really do and how they work.  It may not be
perfectly accurate (I'm still learning...) but my code is now able to
parse the FDEs generated by GCC so it can't be too far off either.

	--david

/* This header file defines the format of a DWARF exception-header
   section (.eh_frame_hdr, pointed to by program-header
   PT_GNU_EH_FRAME).  The exception-header is self-describing in the
   sense that the format of the addresses contained in it is expressed
   as a one-byte type-descriptor called a "pointer-encoding" (PE).

   The exception header encodes the address of the .eh_frame section
   and optionally contains a binary search table for the
   Frame Descriptor Entries (FDEs) in the .eh_frame.  The contents of
   .eh_frame has the format described by the DWARF v3 standard
   (http://www.eagercon.com/dwarf/dwarf3std.htm), except that code
   addresses may be encoded in different ways.  Also, .eh_frame has
   augmentations that allow encoding a language-specific data-area
   (LSDA) pointer and a pointer to a personality-routine.

   Details:

    The Common Information Entry (CIE) associated with an FDE may
    contain an augmentation string.  Each character in this string has
    a specific meaning and either one or two associated operands.  The
    operands are stored in an augmentation body which appears right
    after the "return_address_register" member and before the
    "initial_instructions" member.  The operands appear in the order
    in which the characters appear in the string.  For example, if the
    augmentation string is "zL", the operand for 'z' would be first in
    the augmentation body and the operand for 'L' would be second.
    The following characters are supported for the CIE augmentation
    string:

     'z': The operand for this character is a uleb128 value that gives the
	  length of the CIE augmentation body, not counting the length
	  of the uleb128 operand itself.  If present, this code must
	  appear as the first character in the augmentation body.

     'L': Indicates that the FDE's augmentation body contains an LSDA
          pointer.  The operand for this character is a single byte
          that specifies the pointer-encoding (PE) that is used for
          the LSDA pointer.

     'R': Indicates that the code-pointers (FDE members
          "initial_location" and "address_range" and the operand for
          DW_CFA_set_loc) in the FDE have a non-default encoding.  The
          operand for this character is a single byte that specifies
          the pointer-encoding (PE) that is used for the
          code-pointers.  Note: the "address_range" member is always
	  encoded as an absolute value.  Apart from that, the specified
	  FDE pointer-encoding applies.

     'P': Indicates the presence of a personality routine (handler).
          The first operand for this character specifies the
	  pointer-encoding (PE) that is used for the second operand,
	  which specifies the address of the personality routine.

    If the augmentation string contains any other characters, the
    remainder of the augmentation string should be ignored.
    Furthermore, if the size of the augmentation body is unknown
    (i.e., 'z' is not the first character of the augmentation string),
    then the entire CIE as well all associated FDEs must be ignored.

    A Frame Descriptor Entries (FDE) may contain an augmentation body
    which, if present, appears right after the "address_range" member
    and before the "instructions" member.  The contents of this body
    is implicitly defined by the augmentation string of the associated
    CIE.  The meaning of the characters in the CIE's augmentation
    string as far as FDEs are concerned is as follows:

     'z': The first operand in the FDE's augmentation body specifies
          the total length of the augmentation body as a uleb128 (not
          counting the length of the uleb128 operand itself).

     'L': The operand for this character is an LSDA pointer, encoded
          in the format specified by the corresponding operand in the
          CIE's augmentation body.

*/

-- 
Todd Allen
Concurrent Computer Corporation