llvm.org GIT mirror llvm / 00484d1
Add basic information about SJLJ EH git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79714 91177308-0d34-0410-b5e6-96231b3b80d8 Jim Grosbach 9 years ago
1 changed file(s) with 36 addition(s) and 3 deletion(s). Raw diff Collapse all Expand all
1919
  • Introduction
  • 2020
    2121
  • Itanium ABI Zero-cost Exception Handling
  • 22
  • Setjmp/Longjmp Exception Handling
  • 2223
  • Overview
  • 2324
    2425
  • LLVM Code Generation
  • 103104
    104105
    105106
    107 Setjmp/Longjmp Exception Handling
    108
    109
    110
    111
    112

    Setjmp/Longjmp (SJLJ) based exception handling uses LLVM intrinsics

    113 llvm.eh.sjlj.setjmp and
    114 llvm.eh.sjlj.longjmp to
    115 handle control flow for exception handling.

    116
    117

    For each function which does exception processing, be it try/catch blocks

    118 or cleanups, that function registers itself on a global frame list. When
    119 exceptions are being unwound, the runtime uses this list to identify which
    120 functions need processing.

    121
    122

    Landing pad selection is encoded in the call site entry of the function

    123 context. The runtime returns to the function via
    124 llvm.eh.sjlj.longjmp, where
    125 a switch table transfers control to the appropriate landing pad based on
    126 the index stored in the function context.

    127
    128

    In contrast to DWARF exception handling, which encodes exception regions

    129 and frame information in out-of-line tables, SJLJ exception handling
    130 builds and removes the unwind frame context at runtime. This results in
    131 faster exception handling at the expense of slower execution when no
    132 exceptions are thrown. As exceptions are, by their nature, intended for
    133 uncommon code paths, DWARF exception handling is generally preferred to
    134 SJLJ.

    135
    136
    137
    138
    106139 Overview
    107140
    108141
    281314 from the landing pad to clean up code and then to the first catch. Since the
    282315 required clean up for each invoke in a try may be different
    283316 (e.g. intervening constructor), there may be several landing pads for a given
    284 try. If cleanups need to be run, the number zero should be passed as the
    317 try. If cleanups need to be run, an i32 0 should be passed as the
    285318 last llvm.eh.selector argument.
    286 However for C++ a null i8* must
    287 be passed instead.>
    319 However, when using DWARF exception handling with C++, a i8* null>
    320 must be passed instead.

    288321
    289322
    290323