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 @@ Exception Handling in LLVM - @@ -20,6 +20,7 @@
  • Introduction
    1. Itanium ABI Zero-cost Exception Handling
      2. +
    2. Setjmp/Longjmp Exception Handling
    3. Overview
  • LLVM Code Generation @@ -56,7 +57,7 @@ -
    Introduction
    +
    Introduction
    @@ -103,6 +104,38 @@
    + +
    + Setjmp/Longjmp Exception Handling +
    + +
    + +

    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.

    +
    +
    Overview @@ -263,10 +296,17 @@
  • __cxa_begin_catch takes a exception structure reference as an argument 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.
    • +
  • __cxa_end_catch takes no arguments. This function:

    +
      +
    1. Locates the most recently caught exception and decrements its handler + count,
      2. +
    2. Removes the exception from the "caught" stack if the handler count + goes to zero, and
      3. +
    3. Destroys the exception if the handler count goes to zero, and the + exception was not re-thrown by throw.
      4. +
    +

    Note: a rethrow from within the catch may replace this call with + a __cxa_rethrow.

    • @@ -283,10 +323,10 @@ from the landing pad to clean up code and then to the first catch. Since the required clean up for each invoke in a try may be different (e.g. intervening constructor), there may be several landing pads for a given - try. If cleanups need to be run, the number zero should be passed as the + try. If cleanups need to be run, an i32 0 should be passed as the last llvm.eh.selector argument. - However for C++ a null i8* must - be passed instead.

    + However, when using DWARF exception handling with C++, a i8* null + must be passed instead.

    @@ -362,10 +402,10 @@
    + 
    -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*)

    - llvm.eh.sjlj.lsda + llvm.eh.sjlj.longjmp
    + 
    -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.

    +
    + +
    + llvm.eh.sjlj.lsda +
    + +
    + +
    +  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.