General information about the Windows x64 exception handling mechanism can be
found at `MSDN Exception Handling (x64)
-<https://msdn.microsoft.com/en-us/library/1eyas8tf(v=vs.80).aspx>_`.
+<https://msdn.microsoft.com/en-us/library/1eyas8tf(v=vs.80).aspx>`_.
Overview
--------
exceptions and throws a third.
When all cleanups are finished, if the exception is not handled by the current
-function, resume unwinding by calling the `resume
-instruction <LangRef.html#i_resume>`_, passing in the result of the
-``landingpad`` instruction for the original landing pad.
+function, resume unwinding by calling the :ref:`resume instruction <i_resume>`,
+passing in the result of the ``landingpad`` instruction for the original
+landing pad.
Throw Filters
-------------
not yet fully implemented. The text below describes how it will work
when completed.)
-The Windows runtime function for C++ exception handling uses a mutli-phase
+The Windows runtime function for C++ exception handling uses a multi-phase
approach. When an exception occurs it searches the current callstack for a
frame that has a handler for the exception. If a handler is found, it then
calls the cleanup handler for each frame above the handler which has a
.. code-block:: llvm
- i8* @llvm.eh.begincatch(i8* %exn)
+ void @llvm.eh.begincatch(i8* %ehptr, i8* %ehobj)
This intrinsic marks the beginning of catch handling code within the blocks
depends on the compilation target and the personality function associated
with the ``landingpad`` instruction.
-The argument to this intrinsic is a pointer that was previously extracted from
-the aggregate return value of the ``landingpad`` instruction. The return
-value of the intrinsic is a pointer to the exception object to be used by the
-catch code. This pointer is returned as an ``i8*`` value, but the actual type
-of the object will depend on the exception that was thrown.
+The first argument to this intrinsic is a pointer that was previously extracted
+from the aggregate return value of the ``landingpad`` instruction. The second
+argument to the intrinsic is a pointer to stack space where the exception object
+should be stored. The runtime handles the details of copying the exception
+object into the slot. If the second parameter is null, no copy occurs.
Uses of this intrinsic are generated by the C++ front-end. Many targets will
use implementation-specific functions (such as ``__cxa_begin_catch``) instead
intrinsic serves as a placeholder to delimit code before a catch handler is
outlined. After the handler is outlined, this intrinsic is simply removed.
+.. _llvm.eh.actions:
+
+``llvm.eh.actions``
+----------------------
+
+.. code-block:: llvm
+
+ void @llvm.eh.actions()
+
+This intrinsic represents the list of actions to take when an exception is
+thrown. It is typically used by Windows exception handling schemes where cleanup
+outlining is required by the runtime. The arguments are a sequence of ``i32``
+sentinels indicating the action type followed by some pre-determined number of
+arguments required to implement that action.
+
+A code of ``i32 0`` indicates a cleanup action, which expects one additional
+argument. The argument is a pointer to a function that implements the cleanup
+action.
+
+A code of ``i32 1`` indicates a catch action, which expects three additional
+arguments. Different EH schemes give different meanings to the three arguments,
+but the first argument indicates whether the catch should fire, the second is a
+pointer to stack object where the exception object should be stored, and the
+third is the code to run to catch the exception.
+
+For Windows C++ exception handling, the first argument for a catch handler is a
+pointer to the RTTI type descriptor for the object to catch. The third argument
+is a pointer to a function implementing the catch. This function returns the
+address of the basic block where execution should resume after handling the
+exception.
+
+For Windows SEH, the first argument is a pointer to the filter function, which
+indicates if the exception should be caught or not. The second argument is
+typically null. The third argument is the address of a basic block where the
+exception will be handled. In other words, catch handlers are not outlined in
+SEH. After running cleanups, execution immediately resumes at this PC.
+
+In order to preserve the structure of the CFG, a call to '``llvm.eh.actions``'
+must be followed by an ':ref:`indirectbr <i_indirectbr>`' instruction that jumps
+to the result of the intrinsic call.
+
+``llvm.eh.unwindhelp``
+----------------------
+
+.. code-block:: llvm
+
+ void @llvm.eh.unwindhelp(i8*)
+
+This intrinsic designates the provided static alloca as the unwind help object.
+This object is used by Windows native exception handling on non-x86 platforms
+where xdata unwind information is used. It is typically an 8 byte chunk of
+memory treated as two 32-bit integers.
+
+``llvm.eh.parentframe``
+-----------------------
+
+.. code-block:: llvm
+
+ void @llvm.eh.parentframe(i8*)
+
+This intrinsic designates the provided static alloca as the object which holds
+the address of the parent frame.
+This object is used by Windows native exception handling on non-x86 platforms
+where xdata unwind information is used.
SJLJ Intrinsics
---------------
projects / oota-llvm.git / blobdiff