[libFuzzer] allow users to supply their own implementation of rand
[oota-llvm.git] / docs / ExceptionHandling.rst
index fe6876ad83a792801f5cfe5808a1fa4c04067967..55ffdb45efe9cedb33c6b4be08247d405598fcac 100644 (file)
@@ -77,7 +77,7 @@ representation and a significant restructuring just before code generation.
 
 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
 --------
@@ -278,9 +278,9 @@ there are no catches or filters that require it to.
   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
 -------------
@@ -339,11 +339,11 @@ original context before code generation.
 
 Catch handlers are called with a pointer to the handler itself as the first
 argument and a pointer to the parent function's stack frame as the second
-argument.  The catch handler uses the `llvm.recoverframe
-<LangRef.html#llvm-frameallocate-and-llvm-framerecover-intrinsics>`_ to get a
+argument.  The catch handler uses the `llvm.localrecover
+<LangRef.html#llvm-localescape-and-llvm-localrecover-intrinsics>`_ to get a
 pointer to a frame allocation block that is created in the parent frame using
-the `llvm.allocateframe 
-<LangRef.html#llvm-frameallocate-and-llvm-framerecover-intrinsics>`_ intrinsic.
+the `llvm.localescape
+<LangRef.html#llvm-localescape-and-llvm-localrecover-intrinsics>`_ intrinsic.
 The ``WinEHPrepare`` pass will have created a structure definition for the
 contents of this block.  The first two members of the structure will always be
 (1) a 32-bit integer that the runtime uses to track the exception state of the
@@ -442,7 +442,7 @@ Uses of this intrinsic are generated by the C++ front-end.
 
 .. 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
@@ -450,11 +450,11 @@ following a ``landingpad`` instruction.  The exact behavior of this function
 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
@@ -498,6 +498,51 @@ When used in the native Windows C++ exception handling implementation, this
 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
+the localescape index of the exception object, 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 second
+argument is an index into the argument list of the ``llvm.localescape`` call in
+the main function. The exception object will be copied into the provided stack
+object. If the exception object is not required, this argument should be -1.
+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 negative one. 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.
+
 
 SJLJ Intrinsics
 ---------------