Exception Handling Table

Original address: Https://mentorembedded.github.io/cxx-abi/exceptions.pdf

This section describes the compiler-generated data that enables the runtime to find appropriate information about actions taken when an exception occurs.

Overview

The process of finding exception handling information from the current PC is summarized in:

All the tables are in the "Code" space. The type pointed by the TypeInfo pointer is determined by a GP relative offset.

System Rollback Table

These are described in "64-bit Runtime Architecture andsoftware conventions for IA-64" [2]. The most important domain for C + + exception handling is the "Start" field of the rollback table entry. The call point is saved as a relative offset to the beginning of the program fragment. Note that a program may be decomposed into multiple program fragments.

If a program is broken down and results in multiple program fragments, the Landing field (landing pad) can be located in any possible fragment, and there may even be a specific fragment for the landing field, which usually corresponds to infrequently executed code. However, there is currently no program fragment that corresponds to a particular configuration of multiple landing field fragments (for example, "hot" and "cold" landing fields).

This can only be achieved by copying the rollback table entries and LSDA for each such fragment. Another scenario to consider, where one bit will indicate whether a landing field is relative to a program fragment or a landing field fragment, but the benefits are far from compensating for the loss of space.

Language-specific data regions

A language-specific data region (LSDA) contains pointers to related data, a set of call points, and a set of activity records. Each program fragment from the C + + code (nominally a function) has its own LSDA. Several sections of LSDA use the LEB128 compression scheme, which is described in the "Decoding Exception Records" section.

LSDAHead

The LSDA header contains the fields that are applied in a program fragment. Currently, two domains are defined:

· Landing field start point pointer. This is a self-relative offset to the beginning of the program fragment's Landing field code. The Landing field field in the Call point table is relative to this pointer. A value of 0 indicates that LSDA is empty. Low 4 bit bits reserved. A value of 0000 means that there is a type table pointer. A value of 0001 means that there are no type table pointers. In the remainder of this document, this address is called Lpstart.

· The type table pointer. This is a self-relative offset to the type table (catch clause and exception description type), described in the "Capture terms" section. If the low 4-bit value of the landing field offset is 0001, the word does not exist. In the remainder of this document, this address is called Ttbase.

Call Point Table

The call point table is a set of call points that may throw an exception (including a throw statement for C + +) in the program fragment. It follows the LSDA head. Each item represents, for a given invocation, the first corresponding activity record with the corresponding landing field.

The beginning of this table is the number of bytes, which is saved as an LEB128, compressed, unsigned integer. followed by the record. They are sorted in ascending order of the call point address. Each record indicates:

· The location of the call point,

· The location of the landing site,

· The first activity record of the call point.

Call Point record field:

The offset of the call point relative to the previous call point, in 16-byte blocks [1]. The first call point is counted relative to the beginning of the program fragment.

The offset of the landing field in 16-byte blocks, relative to the Lpstart address.

The offset of the first related activity record relative to the start of the active table. This value deviates by 1 (1 indicates the start of the active table), and 0 indicates that no activity exists.

All domains of the Landing Field table are compressed using LEB128 encoding (described in the "Decoding Exception Records" section).

A missing item in the call Point table indicates that a call should not throw an exception. Such calls include the following:

· The invocation of destructors in cleanup code. C + + semantics prohibit these calls from throwing exceptions.

· A call to an intrinsic function that is known to not throw an exception in the standard library (sin,memcpy).

If the routine cannot find the call point item for a given call, it will call terminate ().

Activity Table

In LSDA, the active table follows the call point table. Each record is one of two types:

· Capture terms, described in the "Capture terms" section.

· Exception specification, described in the "Exception Specification" section.

The two record types have the same format, with only a small difference. They are distinguished by the "Switch value" field: The catch clause has a positive toggle value, and the exception specification has a negative switching value. A value of 0 represents a catch-all clause.

Active record field:

Type filter: The type that is used by the runtime to match the type of the exception that is thrown and the type of the catch clause or exception specification.

Activity record: The self-related signed byte digit shift to the next activity, 0 indicates that there is no next activity record.

All domains are compressed using LEB128 encoding (described in the "Decoding Exception Records" section). The structure of the active table is determined by the C + + front end, but is subject to inline and other optimizations. Code generation is responsible for assigning the actual switching value to the "Next record" offset.

Capture terms

The code that follows the catch clause of the same try is similar to a switch statement. The capture terms activity record notifies the runtime about the type of a catch clause and the associated toggle value.

Note When an exception is thrown with a different type, the runtime may apply some transformations (refer to ISO c++final Draft International Standard 15.3.3 Section [Except.handler] for acceptable conversions). Therefore, pointers such as type information cannot be used directly as toggle values.

Active record field:

Filter value: Positive number, starting from 1. The index of the type table that captures the terms __typeinfo type. 1 is the first word before ttbase, 2 is the second word, and so on. Used by the runtime to check whether the thrown exception type matches the catch clause type. The backend generates a switch statement that checks for this value.

Next: The signed offset, starting from this field to the number of bytes of the next linked activity record, if not 0.

All domains are compressed using LEB128 encoding (described in the "Decoding Exception Records" section).

The sequence of activity records determined by the next field is the order in which the capture terms appear in the source code, and they must be consistent. The C + + language allows two catch clauses in the same function to cover related types (such as base classes and derived classes). Therefore, changing the order of the capture clauses will change the semantics of the program.

run-time activity: If the exception type is thrown to match the catch clause type, the toggle value of the activity record is passed to the "switch selector" argument of the landing farm when it is run.

Front End: The front end produces a XHJP operator that invokes this activity record.

Backend : The back end assigns a toggle value. If two XHJP operators can be reached from the same landing field, they cannot share any of the switching values except for the exact same type. The XHJP operator is converted to a switch statement, and if the value of the switch selector matches the toggle value of the active record, it jumps to the capture clause code.

Exception specification

An violation of the exception specification is represented by the runtime by setting the value of the switch selector to a negative number. The code in the landing field checks to see if the switch selector value is negative, and if so, calls the __cxa_unexpected routine. Otherwise, the exception is propagated.

Active record field:

C + + Type list: Negative number, starting from 1, which is a byte offset in the type table with the type index ending with a null character. On-1, the list will be in Ttbase+1, 2 on the ttbase+2, and so on. Used by the runtime to match the type specified in the throw exception type with the "throw" list. The backend generates a switch statement to check for this particular value.

Next: The signed offset, starting from this field to the number of bytes of the next linked activity record, if not 0.

All domains are compressed using LEB128 encoding (described in the "Decoding Exception Records" section).

The behavior of the exception specification is very similar to the catch clause: When an exception is thrown that violates the exception rule, a rollback of 1 means that a handle is found, and the rollback of 2 in the generated code gives control to a handle.

run-time activity: The exception Handling library checks whether the thrown exception is in the list of possible exception types. If not, it sets the "switch selector" argument of the landing field to the negative value indicated.

front-end generation code: The generated code of an exception specification handle checks whether the value of the switch selector is an appropriate negative number. If not, the exception is spread out.

S1:

//corresponding to an XHJP statement

Switch (Switchselector)

{

Case Negative_switch_value: gotoH1

}

X1:

[RESX]

H1:

__cxa_unexpected ();

Note After a function is inline with one exception specification, some code may actually use the switch selector value in the calling function, and if the negative value specified in the matching activity record fails, the control falls to the "default" exit.

Type table

The type table is an array of non-compressed GP relative offsets to the __type_info object that describes the C + + type. The filter value in the capture terms record is the index of this array. This type is generated by the backend.

For example, in a section of code that contains catch (A), catch (B), and catch (c), the table might contain:

· Ttbase the first word of a in the __type_info, corresponding to the filter value of 1.

· Ttbase the second word of B in the __type_info, corresponding to the filter value of 2.

· Ttbase the third word in C of the __type_info, corresponding to the filter value of 3.

Exception Specification Table

This table contains a list of types used in the exception specification. These lists are sequences that are the end of a null character for a type table compression cable. This table is generated by the backend.

For example, given the type description in the previous section, we can encode two functions that use throw (A, b) with throw (C) using the following bytes:

0,

0 //throw (A, B)

3,0 //throw (C)

In an activity record, the exception is encoded as a negative number offset from the beginning of the table. The throw (A, B) will have a filter value of 1, while throw (C) has a filter value of-4.

Note the type indexes may be more than one byte (they are LEB128 encoded).

Decoding Exception Records

As noted in the section on Activity records and rollback tables, almost all of the fields in the exception table are saved in a compressed format to save space. The format used is little-endianbase (LEB128). This is the same compression scheme as the dwarf target model format.

To decode LEB128:

· Collects a series of bytes with high bit bits set, followed by a byte with no high bit set. (the highest bit is 0 for a tag that ends with a LEB128 value).

· Discards the highest bits per byte. The remaining n 7-bit bytes.

· A 7N bit binary number is formed from these bytes in the order of the small ends (the last byte is the highest bit).

· If the value is signed, it is parsed with twos complement and the highest bit is the sign bit.

to encode LEB128:

· The value is decomposed into a combination of 7 bits, starting from the lowest bit (small-endian).

· If the value is unsigned, the last group 0 is expanded to an integer of 7 bits. If the value is signed, the last value symbol is expanded to a whole of 7 bits.

· Discards the leading 0 of all groups (that is, 7th bit), but if the value is 0, keep at least the first group (the lowest bit). If the value is signed, discard the repeating leading 1 (symbol extension) in all groups, but be sure to keep at least one sign bit (refer to the example below-128).

· The highest position for all groups other than the last group is 1, and the highest position of the last group is 0.

Example (marker bit bold, sign bit underlined):

leb128-encoded values                                        Binary Values                                      Value (Signed)

0 0 000000                                                 0 000000                                        0

0 0 111111                                                 0 111111                                        63

0 1111111 1111111 127 (-1)

10000000 00000001 00000010000000 128

10000001 00000001 00000010000001 129

10000000 01111111 11111110000000 16256 ( -128)

10001000 00001100 00011000001000 1544

10000000 01000000 10000000000000 8192 ( -4096)

10001010 10000101 00000011 000001100001010001010 49802

Rolling back the Library interface

This section defines the rollback library interface that is exported as a generic C + + ABI.

The rollback library interface includes at least the following routines:

_unwind_raiseexception,

_unwind_resume,

_unwind_deleteexception,

_UNWIND_GETGR,

_UNWIND_SETGR,

_unwind_getip,

_unwind_setip,

_unwind_getregionstart,

_unwind_getlanguagespecificdata,

_unwind_forcedunwind

In addition, two data types (_unwind_context and _unwind_exception) are defined for contacting a calling runtime and the above routines. The behavior of all routines and interfaces is like defining the extern "C". In particular, these names are not decorated.

Finally, a language-to-vendor-specific personality routine is saved by the compiler in the rollback descriptor of the stack frame that requires exception handling. This personality routine is called by the rollback to handle language-specific tasks, such as identifying frames that handle a particular exception.

Design Discussion

There are two main reasons for rolling back a stack:

· exceptions, as defined by the language that supports them (for example, C + +)

· "Forced" rollback (for example, caused by longjump or thread termination).

The interface described here attempts to remain similar. However, there is a major difference.

· In the case where an exception is thrown, the stack is rolled back at the same time as the exception is propagated, but it is expected that each runtime knows whether to catch the exception or leave it alone. This task is delegated to the personality routine, which is assumed to behave correctly for any type of exception, whether "native" or "foreign". Some guidelines for "correct behavior" are given below.

· On the other side, an external force pushes the rollback during the "force rollback" process. For example, this can be a longjump routine. This external force, rather than each personality routine, knows when to stop rolling back. The fact that the personality routine is not given a choice about whether to roll back further is represented by the eh_force_unwind_flag tag.

To reconcile these differences, two different routines were proposed. _unwind_raiseexception performs a rollback under the control of the personality routine. On the other hand, _unwind_forceunwind performs a rollback, but gives an "external force" an opportunity to intercept a call to personality such as. This is done by using a proxy personality routine that intercepts the call to the personality routine, allowing the external force to replace the default value of the personality routine.

[1] The IA64 schema indicates that a single call will be executed in a given block. Multiple calls may be placed in a single block (for example, in a like a? B (): The expression of C (), only if they can share the same landing field.

Exception Handling Table