This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
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@napali.hpl.hp.com><20031216214906.GA31351@redhat.com>
- Reply-to: davidm at hpl dot hp dot com
>>>>> On Tue, 16 Dec 2003 13:49:06 -0800, Richard Henderson <rth@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.
*/