CbC/CbC_llvm: docs/ExceptionHandling.rst comparison

comparison docs/ExceptionHandling.rst @ 77:54457678186b LLVM3.6

LLVM 3.6

author	Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
date	Mon, 08 Sep 2014 22:06:00 +0900
parents	95c75e76d11b
children	60c9769439b8

comparison

equal deleted inserted replaced

-:e874dbf0ad9d
+:54457678186b
 #. where to continue when the call succeeds as per normal, and
 #. where to continue if the call raises an exception, either by a throw or the
 unwinding of a throw
-The term used to define a the place where an ``invoke`` continues after an
+The term used to define the place where an ``invoke`` continues after an
 exception is called a *landing pad*. LLVM landing pads are conceptually
 alternative function entry points where an exception structure reference and a
 type info index are passed in as arguments. The landing pad saves the exception
 structure reference and then proceeds to select the catch block that corresponds
 to the type info of the exception object.
 the *selector value* respectively.
 The ``landingpad`` instruction takes a reference to the personality function to
 be used for this ``try``/``catch`` sequence. The remainder of the instruction is
 a list of *cleanup*, *catch*, and *filter* clauses. The exception is tested
-against the clauses sequentially from first to last. The selector value is a
+against the clauses sequentially from first to last. The clauses have the
-positive number if the exception matched a type info, a negative number if it
+following meanings:
-matched a filter, and zero if it matched a cleanup. If nothing is matched, the
-behavior of the program is `undefined`_. If a type info matched, then the
+-  ``catch <type> @ExcType``
-selector value is the index of the type info in the exception table, which can
-be obtained using the `llvm.eh.typeid.for`_ intrinsic.
+- This clause means that the landingpad block should be entered if the
+exception being thrown is of type ``@ExcType`` or a subtype of
+``@ExcType``. For C++, ``@ExcType`` is a pointer to the ``std::type_info``
+object (an RTTI object) representing the C++ exception type.
+- If ``@ExcType`` is ``null``, any exception matches, so the landingpad
+should always be entered. This is used for C++ catch-all blocks ("``catch
+(...)``").
+- When this clause is matched, the selector value will be equal to the value
+returned by "``@llvm.eh.typeid.for(i8* @ExcType)``". This will always be a
+positive value.
+-  ``filter <type> [<type> @ExcType1, ..., <type> @ExcTypeN]``
+- This clause means that the landingpad should be entered if the exception
+being thrown does *not* match any of the types in the list (which, for C++,
+are again specified as ``std::type_info`` pointers).
+- C++ front-ends use this to implement C++ exception specifications, such as
+"``void foo() throw (ExcType1, ..., ExcTypeN) { ... }``".
+- When this clause is matched, the selector value will be negative.
+- The array argument to ``filter`` may be empty; for example, "``[0 x i8**]
+undef``". This means that the landingpad should always be entered. (Note
+that such a ``filter`` would not be equivalent to "``catch i8* null``",
+because ``filter`` and ``catch`` produce negative and positive selector
+values respectively.)
+-  ``cleanup``
+- This clause means that the landingpad should always be entered.
+- C++ front-ends use this for calling objects' destructors.
+- When this clause is matched, the selector value will be zero.
+- The runtime may treat "``cleanup``" differently from "``catch <type>
+null``".
+In C++, if an unhandled exception occurs, the language runtime will call
+``std::terminate()``, but it is implementation-defined whether the runtime
+unwinds the stack and calls object destructors first. For example, the GNU
+C++ unwinder does not call object destructors when an unhandled exception
+occurs. The reason for this is to improve debuggability: it ensures that
+``std::terminate()`` is called from the context of the ``throw``, so that
+this context is not lost by unwinding the stack. A runtime will typically
+implement this by searching for a matching non-``cleanup`` clause, and
+aborting if it does not find one, before entering any landingpad blocks.
 Once the landing pad has the type info selector, the code branches to the code
 for the first catch. The catch then checks the value of the type info selector
 against the index of type info for that catch.  Since the type info index is not
 known until all the type infos have been gathered in the backend, the catch code
 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 of
 ``landingpad`` instruction.  The single argument is a reference to a type info.
+Uses of this intrinsic are generated by the C++ front-end.
+SJLJ Intrinsics
+---------------
+The ``llvm.eh.sjlj`` intrinsics are used internally within LLVM's
+backend.  Uses of them are generated by the backend's
+``SjLjEHPrepare`` pass.
 .. _llvm.eh.sjlj.setjmp:
 ``llvm.eh.sjlj.setjmp``
------------------------
+~~~~~~~~~~~~~~~~~~~~~~~
 .. code-block:: llvm
 i32 @llvm.eh.sjlj.setjmp(i8* %setjmp_buf)
 available for use in a target-specific manner.
 .. _llvm.eh.sjlj.longjmp:
 ``llvm.eh.sjlj.longjmp``
-------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~
 .. code-block:: llvm
 void @llvm.eh.sjlj.longjmp(i8* %setjmp_buf)
 a buffer populated by `llvm.eh.sjlj.setjmp`_. The frame pointer and stack
 pointer are restored from the buffer, then control is transferred to the
 destination address.
 ``llvm.eh.sjlj.lsda``
----------------------
+~~~~~~~~~~~~~~~~~~~~~
 .. code-block:: llvm
 i8* @llvm.eh.sjlj.lsda()
 the address of the Language Specific Data Area (LSDA) for the current
 function. The SJLJ front-end code stores this address in the exception handling
 function context for use by the runtime.
 ``llvm.eh.sjlj.callsite``
--------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~
 .. code-block:: llvm
 void @llvm.eh.sjlj.callsite(i32 %call_site_num)

Mercurial > hg > CbC > CbC_llvm

comparison docs/ExceptionHandling.rst @ 77:54457678186b LLVM3.6