X-Git-Url: http://demsky.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FExceptionHandling.html;h=bbc45656a41f254f196d45afb83434519d5a3711;hb=20a70c8472c5509a4f51654826bec8a0b5a817c4;hp=166fe4cf11d7cb6ef91f73e35ff3a2f7e2953f71;hpb=c4f661e3dec2e574a59d32bef8679af832349fd2;p=oota-llvm.git diff --git a/docs/ExceptionHandling.html b/docs/ExceptionHandling.html index 166fe4cf11d..bbc45656a41 100644 --- a/docs/ExceptionHandling.html +++ b/docs/ExceptionHandling.html @@ -4,7 +4,7 @@
Setjmp/Longjmp (SJLJ) based exception handling uses LLVM intrinsics + llvm.eh.sjlj.setjmp and + llvm.eh.sjlj.longjmp to + handle control flow for exception handling.
+ +For each function which does exception processing, be it try/catch blocks + or cleanups, that function registers itself on a global frame list. When + exceptions are being unwound, the runtime uses this list to identify which + functions need processing.
+ +
Landing pad selection is encoded in the call site entry of the function + context. The runtime returns to the function via + llvm.eh.sjlj.longjmp, where + a switch table transfers control to the appropriate landing pad based on + the index stored in the function context.
+ +In contrast to DWARF exception handling, which encodes exception regions + and frame information in out-of-line tables, SJLJ exception handling + builds and removes the unwind frame context at runtime. This results in + faster exception handling at the expense of slower execution when no + exceptions are thrown. As exceptions are, by their nature, intended for + uncommon code paths, DWARF exception handling is generally preferred to + SJLJ.
+Note: a rethrow from within the catch may replace this call with + a __cxa_rethrow.
-i8* %llvm.eh.exception( ) + i8* %llvm.eh.exception()-
This intrinsic returns a pointer to the exception structure.
@@ -377,11 +417,10 @@ i8* %llvm.eh.exception( )-i32 %llvm.eh.selector.i32(i8*, i8*, i8*, ...) -i64 %llvm.eh.selector.i64(i8*, i8*, i8*, ...) + i32 %llvm.eh.selector(i8*, i8*, i8*, ...)-
This intrinsic is used to compare the exception with the given type infos, filters and cleanups.
@@ -410,11 +449,10 @@ i64 %llvm.eh.selector.i64(i8*, i8*, i8*, ...)-i32 %llvm.eh.typeid.for.i32(i8*) -i64 %llvm.eh.typeid.for.i64(i8*) + i32 %llvm.eh.typeid.for(i8*)-
This intrinsic returns the type info index in the exception table of the current function. This value can be used to compare against the result @@ -429,10 +467,10 @@ i64 %llvm.eh.typeid.for.i64(i8*)
-i32 %llvm.eh.sjlj.setjmp(i8*) + 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 @@ -454,14 +492,34 @@ i32 %llvm.eh.sjlj.setjmp(i8*)
-i8* %llvm.eh.sjlj.lsda( ) + void %llvm.eh.sjlj.setjmp(i8*)+ +
The llvm.eh.sjlj.longjmp + intrinsic is used to implement __builtin_longjmp() for SJLJ + style exception handling. The single parameter is a pointer to a + buffer populated by + llvm.eh.sjlj.setjmp. The frame pointer and stack pointer + are restored from the buffer, then control is transfered to the + destination address.
++ i8* %llvm.eh.sjlj.lsda() +
Used for SJLJ based exception handling, the llvm.eh.sjlj.lsda intrinsic returns the address of the Language @@ -477,15 +535,15 @@ i8* %llvm.eh.sjlj.lsda( )
-void %llvm.eh.sjlj.callsite(i32) + void %llvm.eh.sjlj.callsite(i32)-
The SJLJ front-end allocates call site indices for invoke instrucitons. - These values are passed to the back-end via the - llvm.eh.sjlj.callsite - intrinsic, where they are used to build the LSDA call-site table.
+For SJLJ based exception handling, the + llvm.eh.sjlj.callsite intrinsic identifies the callsite value + associated with the following invoke instruction. This is used to ensure + that landing pad entries in the LSDA are generated in the matching order.