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 C++ exception specifications, such as
214 In C++, if an unhandled exception occurs, the language runtime will call
217 C++ unwinder does not call object destructors when an unhandled exception
235 * ``__cxa_begin_catch`` takes an exception structure reference as an argument
236 and returns the value of the exception object.
240 #. Locates the most recently caught exception and decrements its handler
243 #. Removes the exception from the *caught* stack if the handler count goes to
246 #. Destroys the exception if the handler count goes to zero and the exception
267 Do not allow a new exception to propagate out of the execution of a
273 When all cleanups are finished, if the exception is not handled by the current
281 C++ allows the specification of which exception types may be thrown from a
286 if the exception does not match any of the type infos. If no match is found then
289 exception structure. Note that the most general form of a ``landingpad``
292 such ``landingpad`` instructions due to inlining creating nested exception
303 doesn't do so unless the exception is actually caught somewhere further up the
313 the selector results they understand and then resume exception propagation with
317 Exception Handling Intrinsics
321 intrinsic functions (name prefixed with ``llvm.eh``) to provide exception
334 This intrinsic returns the type info index in the exception table of the current
357 argument to the intrinsic is a pointer to stack space where the exception object
358 should be stored. The runtime handles the details of copying the exception
366 When used in the native Windows C++ exception handling implementation, this
369 by instructions that retrieve the exception object pointer from the frame
399 When used in the native Windows C++ exception handling implementation, this
414 This intrinsic retrieves a pointer to the exception caught by the given
434 For SJLJ based exception handling, this intrinsic forces register saving for the
456 For SJLJ based exception handling, the ``llvm.eh.sjlj.longjmp`` intrinsic is
469 For SJLJ based exception handling, the ``llvm.eh.sjlj.lsda`` intrinsic returns
471 function. The SJLJ front-end code stores this address in the exception handling
481 For SJLJ based exception handling, the ``llvm.eh.sjlj.callsite`` intrinsic
489 There are two tables that are used by the exception handling runtime to
490 determine which actions should be taken when an exception is thrown.
492 Exception Handling Frame
495 An exception handling frame ``eh_frame`` is very similar to the unwind frame
498 an exception handling frame for each function in a compile unit, plus a common
499 exception handling frame that defines information common to all functions in the
508 Exception Tables
511 An exception table contains information about what actions to take when an
512 exception is thrown in a particular part of a function's code. This is typically
516 There is one exception table per function, except leaf functions and functions
517 that have calls only to non-throwing functions. They do not need an exception
522 Exception Handling using the Windows Runtime
533 Under Itanium, throwing an exception typically involes allocating thread local
534 memory to hold the exception, and calling into the EH runtime. The runtime
535 identifies frames with appropriate exception handling actions, and successively
542 handling the exception calls ``__cxa_end_catch`` to destroy the exception,
546 Instead, the active exception is typically described by a frame on the stack.
547 In the case of C++ exceptions, the exception object is allocated in stack memory
551 personality routine, which decides what actions to take to handle the exception.
568 runtime must use funclets for catch bodies because the C++ exception object is
569 allocated in a child stack frame of the function handling the exception. If the
571 exception would be overwritten quickly by subsequent function calls. The use of
573 resorting to TLS. Instead, the runtime throws a special exception, and then uses
578 C++ exceptions and general purpose Windows exception handling. Because the C++
579 exception object lives in stack memory, LLVM cannot provide a custom personality
581 to rethrow an exception or continue unwinding. Therefore, LLVM must use the IR
582 constructs described later in this document to implement compatible exception
592 if the exception came from a particular DLL or code region, or if code faulted
602 New exception handling instructions
615 The following new instructions are considered "exception handling pads", in that
620 frontend encounters a call site that may throw an exception, it should emit an
630 indicating where the active exception will unwind to next.
795 ``catchpad``\ s are appropriate for the in-flight exception and it unwinds
826 any exception edges which unwind anywhere other than the caller. This