This is the mail archive of the
mailing list for the GCC project.
Re: Elf-Section .gcc_except_table
- From: Ian Lance Taylor <iant at google dot com>
- To: Martin Kirchengast <martin_kir_ at hotmail dot com>
- Cc: gcc-help at gcc dot gnu dot org
- Date: Mon, 13 Sep 2010 15:23:45 -0700
- Subject: Re: Elf-Section .gcc_except_table
- References: <BLU0-SMTP1964727C8537F2C46327ABCB2770@phx.gbl>
Martin Kirchengast <email@example.com> writes:
> Is there any information about the format of the ELF64 section
> ".gcc_except_table" available? The only information related to
> exception handling tables I found is about the ".eh_frame"
> content. But what is the purpose and the exact format of
I don't know whether the exact format is documented anywhere. The
.gcc_except_table section holds the language specific data area for
unwinding, generally known as the LSDA. It starts with a header, which
is three fields. The first two fields is a 1 byte encoding followed by
a value. The encoding is a DWARF EH encoding; if it is DW_EH_PE_omit,
the value is omitted.
* landing pad base
* handler base
Next is the encoding of the call site entries, than an LEB128 which is
the length of the call site table. Next is the call site table. Each
entry is four data items with the specified encoding.
* start of region relative to start of function
* end of region relative to start of function
* start of landing pad for region relative to start of function, or 0
* action to take (always a uleb128)
While unwinding the stack, the personality function will check whether
the PC is in range of some call site. If it is, a zero landing_pad
means there is nothing to be done.
All the above is called language dependent, but as far as I know it's
used for all of gcc's languages, even though they all have distinct
personality functions. But the action record and the action table
really are language dependent. A zero action record indicates a
cleanup. Otherwise, the action record is an index into the action
table, which immediately follows the call site table. For C++ each
action table entry is a sleb128 filter and an sleb128 displacement. A
filter value of zero is a cleanup. A positive filter value is an index
into the ttype table, and gives the type of the object which the
exception handler expects (0 for NULL). A negative filter is an
exception specification, which means the type of exception which is
permitted. If the filter doesn't match, the personality routine uses
the displacement to get the next action table entry to try. If the
displacement is zero, there are no more, and nothing is done. Otherwise
we've found a positive or negative match and the personality routine
executes the corresponding code by jumping to the landing pad.
So, that is rather vague, but it should give the general idea.
Basically it's where go from stack unwinding to deciding exactly what to
do about an exception.