Lines Matching full:exception
2 Exception Handling in LLVM
12 exception handling in LLVM. It describes the format that LLVM exception
15 provides specific examples of what exception handling information is used for in
18 Itanium ABI Zero-cost Exception Handling
21 Exception handling for most programming languages is designed to recover from
23 exception handling should not interfere with the main flow of an application's
27 The Itanium ABI Exception Handling Specification defines a methodology for
28 providing outlying data in the form of exception tables without inlining
29 speculative exception handling code in the flow of an application's main
33 A more complete description of the Itanium ABI exception handling runtime
34 support of can be found at `Itanium C++ ABI: Exception Handling
36 exception frame format can be found at `Exception Frames
39 <http://dwarfstd.org/Dwarf4Std.php>`_. A description for the C++ exception
40 table formats can be found at `Exception Handling Tables
43 Setjmp/Longjmp Exception Handling
46 Setjmp/Longjmp (SJLJ) based exception handling uses LLVM intrinsics
48 exception handling.
50 For each function which does exception processing --- be it ``try``/``catch``
60 In contrast to DWARF exception handling, which encodes exception regions and
61 frame information in out-of-line tables, SJLJ exception handling builds and
62 removes the unwind frame context at runtime. This results in faster exception
65 exception handling is generally preferred to SJLJ.
67 Windows Runtime Exception Handling
78 When an exception is thrown in LLVM code, the runtime does its best to find a
81 The runtime first attempts to find an *exception frame* corresponding to the
82 function where the exception was thrown. If the programming language supports
83 exception handling (e.g. C++), the exception frame contains a reference to an
84 exception table describing how to process the exception. If the language does
85 not support exception handling (e.g. C), or if the exception needs to be
86 forwarded to a prior activation, the exception frame contains information about
88 activation. This process is repeated until the exception is handled. If the
89 exception is not handled and no activations remain, then the application is
93 exceptions, the exception handling ABI provides a mechanism for
94 supplying *personalities*. An exception handling personality is defined by
96 which receives the context of the exception, an *exception structure*
97 containing the exception object type and value, and a reference to the exception
99 compile unit is specified in a *common exception frame*.
101 The organization of an exception table is language dependent. For C++, an
102 exception table is organized as a series of code ranges defining what to do if
103 an exception occurs in that range. Typically, the information associated with a
104 range defines which types of exception objects (using C++ *type info*) that are
110 receives an *exception structure* and a *selector value* corresponding to the
111 *type* of exception thrown. The selector is then used to determine which *catch*
112 should actually process the exception.
119 implementation of LLVM exception handling in terms of C++ examples.
124 Languages that support exception handling typically provide a ``throw``
125 operation to initiate the exception process. Internally, a ``throw`` operation
128 #. A request is made to allocate exception space for an exception structure.
132 #. A call is made to the runtime to raise the exception, passing the exception
135 In C++, the allocation of the exception structure is done by the
136 ``__cxa_allocate_exception`` runtime function. The exception raising is handled
137 by ``__cxa_throw``. The type of the exception is represented using a C++ RTTI
144 exception. In those circumstances, the LLVM C++ front-end replaces the call with
150 #. where to continue if the call raises an exception, either by a throw or the
154 exception is called a *landing pad*. LLVM landing pads are conceptually
155 alternative function entry points where an exception structure reference and a
156 type info index are passed in as arguments. The landing pad saves the exception
158 to the type info of the exception object.
162 and integer pair corresponding to the pointer to the *exception structure* and
168 *catch*, and *filter* clauses. The exception is tested against the clauses
174 exception being thrown is of type ``@ExcType`` or a subtype of
176 object (an RTTI object) representing the C++ exception type.
178 - If ``@ExcType`` is ``null``, any exception matches, so the landingpad
188 - This clause means that the landingpad should be entered if the exception
192 - C++ front-ends use this to implement the C++ exception specifications, such as
215 In C++, if an unhandled exception occurs, the language runtime will call
218 C++ unwinder does not call object destructors when an unhandled exception
236 * ``__cxa_begin_catch`` takes an exception structure reference as an argument
237 and returns the value of the exception object.
241 #. Locates the most recently caught exception and decrements its handler
244 #. Removes the exception from the *caught* stack if the handler count goes to
247 #. Destroys the exception if the handler count goes to zero and the exception
268 Do not allow a new exception to propagate out of the execution of a
274 When all cleanups are finished, if the exception is not handled by the current
282 Prior to C++17, C++ allowed the specification of which exception types may be
287 if the exception does not match any of the type infos. If no match is found then
290 exception structure. Note that the most general form of a ``landingpad``
293 such ``landingpad`` instructions due to inlining creating nested exception
302 doesn't do so unless the exception is actually caught somewhere further up the
312 the selector results they understand and then resume exception propagation with
316 Exception Handling Intrinsics
320 intrinsic functions (name prefixed with ``llvm.eh``) to provide exception
333 This intrinsic returns the type info index in the exception table of the current
349 This intrinsic retrieves a pointer to the exception caught by the given
369 For SJLJ based exception handling, this intrinsic forces register saving for the
393 For SJLJ based exception handling, the ``llvm.eh.sjlj.longjmp`` intrinsic is
406 For SJLJ based exception handling, the ``llvm.eh.sjlj.lsda`` intrinsic returns
408 function. The SJLJ front-end code stores this address in the exception handling
418 For SJLJ based exception handling, the ``llvm.eh.sjlj.callsite`` intrinsic
426 There are two tables that are used by the exception handling runtime to
427 determine which actions should be taken when an exception is thrown.
429 Exception Handling Frame
432 An exception handling frame ``eh_frame`` is very similar to the unwind frame
435 an exception handling frame for each function in a compile unit, plus a common
436 exception handling frame that defines information common to all functions in the
445 Exception Tables
448 An exception table contains information about what actions to take when an
449 exception is thrown in a particular part of a function's code. This is typically
453 There is one exception table per function, except leaf functions and functions
454 that have calls only to non-throwing functions. They do not need an exception
459 Exception Handling using the Windows Runtime
470 Under Itanium, throwing an exception typically involves allocating thread local
471 memory to hold the exception, and calling into the EH runtime. The runtime
472 identifies frames with appropriate exception handling actions, and successively
479 handling the exception calls ``__cxa_end_catch`` to destroy the exception,
483 Instead, the active exception is typically described by a frame on the stack.
484 In the case of C++ exceptions, the exception object is allocated in stack memory
488 personality routine, which decides what actions to take to handle the exception.
505 runtime must use funclets for catch bodies because the C++ exception object is
506 allocated in a child stack frame of the function handling the exception. If the
508 exception would be overwritten quickly by subsequent function calls. The use of
510 resorting to TLS. Instead, the runtime throws a special exception, and then uses
515 C++ exceptions and general purpose Windows exception handling. Because the C++
516 exception object lives in stack memory, LLVM cannot provide a custom personality
518 to rethrow an exception or continue unwinding. Therefore, LLVM must use the IR
519 constructs described later in this document to implement compatible exception
529 if the exception came from a particular DLL or code region, or if code faulted
539 New exception handling instructions
552 The following new instructions are considered "exception handling pads", in that
557 frontend encounters a call site that may throw an exception, it should emit an
567 indicating where the active exception will unwind to next.
732 ``catchpad``\ s are appropriate for the in-flight exception and it unwinds
763 any exception edges which unwind anywhere other than the caller. This
780 Exception Handling support on the target
783 In order to support exception handling on particular target, there are a few
794 by th unwinder to unwind stack during exception handling.
799 passes the *exception structure* (a pointer) and *selector value* (an integer)