Martin Kirchengast <martin_kir_@xxxxxxxxxxx> 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 > ".gcc_except_table"? 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. Ian
