-
@@ -72,21 +74,20 @@ C/C++.
Testing/Testing/Testing.
+Testing/Testing/Testing.
Exception handling for most programming languages is designed to recover from conditions that rarely occur during general use of an application. To that end, exception handling should not interfere with the main flow of an -application's algorithm by performing checkpointing tasks such as saving +application's algorithm by performing checkpointing tasks such as saving the current pc or register state.
The Itanium ABI Exception Handling Specification defines a methodology for providing outlying data in the form of exception tables without inlining -speculative exception handling code in the flow of an application's main +speculative exception handling code in the flow of an application's main algorithm. Thus, the specification is said to add "zero-cost" to the normal execution of an application.
A more complete description of the Itanium ABI exception handling runtime support of can be found at Itanium C++ ABI: -Exception Handling. A description of the exception frame format can be -found at Exception Frames, with details of the Dwarf specification at Dwarf 3 Standard. A description for the C++ exception table formats can be found at @@ -204,10 +205,9 @@ to the type info of the exception object.
pad to the back end.llvm.eh.exception takes no -arguments and returns the exception structure reference. The backend replaces -this intrinsic with the code that accesses the first argument of a call. The -LLVM C++ front end generates code to save this value in an alloca location for -further use in the landing pad and catch code.
+arguments and returns a pointer to the exception structure. This only returns a +sensible value if called after an invoke has branched to a landing pad. Due to +codegen limitations, it must currently be called in the landing pad itself.llvm.eh.selector takes a minimum of three arguments. The first argument is the reference to the exception @@ -221,8 +221,9 @@ The result of the llvm.eh.selector is a positive number if the exception matched a type info, a negative number if it matched a filter, and zero if it matched a cleanup. If nothing is matched, the behaviour of the program is undefined. -The LLVM C++ front end generates code to save the selector value in an alloca -location for further use in the landing pad and catch code. +This only returns a sensible value if called after an invoke has branched to a +landing pad. Due to codegen limitations, it must currently be called in the +landing pad itself. If a type info matched then the selector value is the index of the type info in the exception table, which can be obtained using the llvm.eh.typeid.for intrinsic.
@@ -243,7 +244,7 @@ selector.Finally, the entry and exit of catch code is bracketed with calls to __cxa_begin_catch and __cxa_end_catch. __cxa_begin_catch takes a exception structure reference as an argument -and returns the value of the exception object. __cxa_end_catch +and returns the value of the exception object. __cxa_end_catch takes a exception structure reference as an argument. This function clears the exception from the exception space. Note: a rethrow from within the catch may replace this call with a __cxa_rethrow.
@@ -277,17 +278,23 @@ instead.C++ allows the specification of which exception types that can be thrown from +
C++ allows the specification of which exception types can be thrown from a function. To represent this a top level landing pad may exist to filter out invalid types. To express this in LLVM code the landing pad will call llvm.eh.selector. The arguments are the -length of the filter expression (the number of type infos plus one), followed by -the type infos themselves. +href="#llvm_eh_selector">llvm.eh.selector. The arguments are a +reference to the exception structure, a reference to the personality function, +the length of the filter expression (the number of type infos plus one), +followed by the type infos themselves. llvm.eh.selector will return a negative value if the exception does not match any of the type infos. If no match is found then a call to __cxa_call_unexpected should be made, otherwise -_Unwind_Resume. Each of these functions require a reference to the -exception structure.
+_Unwind_Resume. Each of these functions requires a reference to the +exception structure. Note that the most general form of an +llvm.eh.selector call can contain +any number of type infos, filter expressions and cleanups (though having more +than one cleanup is pointless). The LLVM C++ front-end can generate such +llvm.eh.selector calls due to inlining +creating nested exception handling scopes.This intrinsic indicates that the exception structure is available at this -point in the code. The backend will replace this intrinsic with code to fetch -the first argument of a call. The effect is that the intrinsic result is the -exception structure reference.
+This intrinsic returns a pointer to the exception structure.
@@ -359,10 +363,8 @@ exception structure reference. i64 %llvm.eh.selector.i64(i8*, i8*, i8*, ...) -This intrinsic indicates that the exception selector is available at this -point in the code. The backend will replace this intrinsic with code to fetch -the second argument of a call. The effect is that the intrinsic result is the -exception selector.
+This intrinsic is used to compare the exception with the given type infos, +filters and cleanups.
llvm.eh.selector takes a minimum of three arguments. The first argument is the reference to the exception @@ -400,6 +402,30 @@ a reference to a type info.
+ + + ++ i32 %llvm.eh.sjlj.setjmp(i8*) ++ +
The SJLJ exception handling uses this intrinsic to force register saving +for the current function and to store the address of the following instruction +for use as a destination address by +llvm.eh.sjlj.longjmp. The buffer format and the overall functioning +of this intrinsic is compatible with the GCC __builtin_setjmp +implementation, allowing code built with the two compilers to interoperate.
+ +The single parameter is a pointer to a five word buffer in which the +calling context is saved. The front end places the frame pointer in the +first word, and the target implementation of this intrinsic should place the +destination address for a +llvm.eh.sjlj.longjmp in the second word. The following three words +are available for use in a target-specific manner.
+An exception table contains information about what actions to take when an -exception is thrown in a particular part of a function's code. There is +exception is thrown in a particular part of a function's code. There is one exception table per function except leaf routines and functions that have only calls to non-throwing functions will not need an exception table.
@@ -455,7 +481,7 @@ only calls to non-throwing functions will not need an exception table.-
-
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS">
LLVM Compiler Infrastructure