• Home
  • Raw
  • Download

Lines Matching refs:exception

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
23 exception handling should not interfere with the main flow of an application's
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
36 exception frame format can be found at `Exception Frames
39 <http://dwarfstd.org/Dwarf4Std.php>`_. A description for the C++ exception
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.
70 When an exception is thrown in LLVM code, the runtime does its best to find a
73 The runtime first attempts to find an *exception frame* corresponding to the
74 function where the exception was thrown. If the programming language supports
75 exception handling (e.g. C++), the exception frame contains a reference to an
76 exception table describing how to process the exception. If the language does
77 not support exception handling (e.g. C), or if the exception needs to be
78 forwarded to a prior activation, the exception frame contains information about
80 activation. This process is repeated until the exception is handled. If the
81 exception is not handled and no activations remain, then the application is
85 exceptions, the exception handling ABI provides a mechanism for
86 supplying *personalities*. An exception handling personality is defined by
88 which receives the context of the exception, an *exception structure*
89 containing the exception object type and value, and a reference to the exception
91 compile unit is specified in a *common exception frame*.
93 The organization of an exception table is language dependent. For C++, an
94 exception table is organized as a series of code ranges defining what to do if
95 an exception occurs in that range. Typically, the information associated with a
96 range defines which types of exception objects (using C++ *type info*) that are
102 receives an *exception structure* and a *selector value* corresponding to the
103 *type* of exception thrown. The selector is then used to determine which *catch*
104 should actually process the exception.
111 implementation of LLVM exception handling in terms of C++ examples.
116 Languages that support exception handling typically provide a ``throw``
117 operation to initiate the exception process. Internally, a ``throw`` operation
120 #. A request is made to allocate exception space for an exception structure.
124 #. A call is made to the runtime to raise the exception, passing the exception
127 In C++, the allocation of the exception structure is done by the
128 ``__cxa_allocate_exception`` runtime function. The exception raising is handled
129 by ``__cxa_throw``. The type of the exception is represented using a C++ RTTI
136 exception. In those circumstances, the LLVM C++ front-end replaces the call with
142 #. where to continue if the call raises an exception, either by a throw or the
146 exception is called a *landing pad*. LLVM landing pads are conceptually
147 alternative function entry points where an exception structure reference and a
148 type info index are passed in as arguments. The landing pad saves the exception
150 to the type info of the exception object.
154 and integer pair corresponding to the pointer to the *exception structure* and
159 a list of *cleanup*, *catch*, and *filter* clauses. The exception is tested
166 exception being thrown is of type ``@ExcType`` or a subtype of
168 object (an RTTI object) representing the C++ exception type.
170 - If ``@ExcType`` is ``null``, any exception matches, so the landingpad
180 - This clause means that the landingpad should be entered if the exception
184 - C++ front-ends use this to implement C++ exception specifications, such as
206 In C++, if an unhandled exception occurs, the language runtime will call
209 C++ unwinder does not call object destructors when an unhandled exception
227 * ``__cxa_begin_catch`` takes an exception structure reference as an argument
228 and returns the value of the exception object.
232 #. Locates the most recently caught exception and decrements its handler
235 #. Removes the exception from the *caught* stack if the handler count goes to
238 #. Destroys the exception if the handler count goes to zero and the exception
259 Do not allow a new exception to propagate out of the execution of a
265 When all cleanups are finished, if the exception is not handled by the current
273 C++ allows the specification of which exception types may be thrown from a
278 if the exception does not match any of the type infos. If no match is found then
281 exception structure. Note that the most general form of a ``landingpad``
284 such ``landingpad`` instructions due to inlining creating nested exception
295 doesn't do so unless the exception is actually caught somewhere further up the
305 the selector results they understand and then resume exception propagation with
313 intrinsic functions (name prefixed with ``llvm.eh``) to provide exception
326 This intrinsic returns the type info index in the exception table of the current
348 For SJLJ based exception handling, this intrinsic forces register saving for the
370 For SJLJ based exception handling, the ``llvm.eh.sjlj.longjmp`` intrinsic is
383 For SJLJ based exception handling, the ``llvm.eh.sjlj.lsda`` intrinsic returns
385 function. The SJLJ front-end code stores this address in the exception handling
395 For SJLJ based exception handling, the ``llvm.eh.sjlj.callsite`` intrinsic
403 There are two tables that are used by the exception handling runtime to
404 determine which actions should be taken when an exception is thrown.
409 An exception handling frame ``eh_frame`` is very similar to the unwind frame
412 an exception handling frame for each function in a compile unit, plus a common
413 exception handling frame that defines information common to all functions in the
419 An exception table contains information about what actions to take when an
420 exception is thrown in a particular part of a function's code. There is one
421 exception table per function, except leaf functions and functions that have
422 calls only to non-throwing functions. They do not need an exception table.