From 00484d15aad5a9732ee0f966ceb68bce90cb9f27 Mon Sep 17 00:00:00 2001 From: Jim Grosbach Date: Sat, 22 Aug 2009 01:42:39 +0000 Subject: Add basic information about SJLJ EH git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79714 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/ExceptionHandling.html | 39 ++++++++++++++++++++++++++++++++++++--- 1 file changed, 36 insertions(+), 3 deletions(-) (limited to 'docs') diff --git a/docs/ExceptionHandling.html b/docs/ExceptionHandling.html index f67954f7e2..72fb349c16 100644 --- a/docs/ExceptionHandling.html +++ b/docs/ExceptionHandling.html @@ -20,6 +20,7 @@
  • Introduction
    1. Itanium ABI Zero-cost Exception Handling
      2. +
    2. Setjmp/Longjmp Exception Handling
    3. Overview
  • LLVM Code Generation @@ -102,6 +103,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 @@ -282,10 +315,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.

    -- cgit v1.2.3