0
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
1 ==========================
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
2 Exception Handling in LLVM
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
3 ==========================
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
4
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
5 .. contents::
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
6 :local:
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
7
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
8 Introduction
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
9 ============
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
10
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
11 This document is the central repository for all information pertaining to
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
12 exception handling in LLVM. It describes the format that LLVM exception
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
13 handling information takes, which is useful for those interested in creating
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
14 front-ends or dealing directly with the information. Further, this document
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
15 provides specific examples of what exception handling information is used for in
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
16 C and C++.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
17
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
18 Itanium ABI Zero-cost Exception Handling
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
19 ----------------------------------------
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
20
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
21 Exception handling for most programming languages is designed to recover from
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
22 conditions that rarely occur during general use of an application. To that end,
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
23 exception handling should not interfere with the main flow of an application's
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
24 algorithm by performing checkpointing tasks, such as saving the current pc or
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
25 register state.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
26
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
27 The Itanium ABI Exception Handling Specification defines a methodology for
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
28 providing outlying data in the form of exception tables without inlining
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
29 speculative exception handling code in the flow of an application's main
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
30 algorithm. Thus, the specification is said to add "zero-cost" to the normal
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
31 execution of an application.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
32
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
33 A more complete description of the Itanium ABI exception handling runtime
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
34 support of can be found at `Itanium C++ ABI: Exception Handling
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
35 <http://mentorembedded.github.com/cxx-abi/abi-eh.html>`_. A description of the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
36 exception frame format can be found at `Exception Frames
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
37 <http://refspecs.linuxfoundation.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html>`_,
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
38 with details of the DWARF 4 specification at `DWARF 4 Standard
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
39 <http://dwarfstd.org/Dwarf4Std.php>`_. A description for the C++ exception
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
40 table formats can be found at `Exception Handling Tables
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
41 <http://mentorembedded.github.com/cxx-abi/exceptions.pdf>`_.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
42
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
43 Setjmp/Longjmp Exception Handling
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
44 ---------------------------------
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
45
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
46 Setjmp/Longjmp (SJLJ) based exception handling uses LLVM intrinsics
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
47 `llvm.eh.sjlj.setjmp`_ and `llvm.eh.sjlj.longjmp`_ to handle control flow for
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
48 exception handling.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
49
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
50 For each function which does exception processing --- be it ``try``/``catch``
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
51 blocks or cleanups --- that function registers itself on a global frame
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
52 list. When exceptions are unwinding, the runtime uses this list to identify
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
53 which functions need processing.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
54
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
55 Landing pad selection is encoded in the call site entry of the function
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
56 context. The runtime returns to the function via `llvm.eh.sjlj.longjmp`_, where
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
57 a switch table transfers control to the appropriate landing pad based on the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
58 index stored in the function context.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
59
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
60 In contrast to DWARF exception handling, which encodes exception regions and
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
61 frame information in out-of-line tables, SJLJ exception handling builds and
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
62 removes the unwind frame context at runtime. This results in faster exception
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
63 handling at the expense of slower execution when no exceptions are thrown. As
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
64 exceptions are, by their nature, intended for uncommon code paths, DWARF
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
65 exception handling is generally preferred to SJLJ.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
66
|
|
83
|
67 Windows Runtime Exception Handling
|
|
|
68 -----------------------------------
|
|
|
69
|
|
95
|
70 LLVM supports handling exceptions produced by the Windows runtime, but it
|
|
|
71 requires a very different intermediate representation. It is not based on the
|
|
|
72 ":ref:`landingpad <i_landingpad>`" instruction like the other two models, and is
|
|
|
73 described later in this document under :ref:`wineh`.
|
|
83
|
74
|
0
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
75 Overview
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
76 --------
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
77
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
78 When an exception is thrown in LLVM code, the runtime does its best to find a
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
79 handler suited to processing the circumstance.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
80
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
81 The runtime first attempts to find an *exception frame* corresponding to the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
82 function where the exception was thrown. If the programming language supports
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
83 exception handling (e.g. C++), the exception frame contains a reference to an
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
84 exception table describing how to process the exception. If the language does
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
85 not support exception handling (e.g. C), or if the exception needs to be
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
86 forwarded to a prior activation, the exception frame contains information about
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
87 how to unwind the current activation and restore the state of the prior
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
88 activation. This process is repeated until the exception is handled. If the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
89 exception is not handled and no activations remain, then the application is
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
90 terminated with an appropriate error message.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
91
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
92 Because different programming languages have different behaviors when handling
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
93 exceptions, the exception handling ABI provides a mechanism for
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
94 supplying *personalities*. An exception handling personality is defined by
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
95 way of a *personality function* (e.g. ``__gxx_personality_v0`` in C++),
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
96 which receives the context of the exception, an *exception structure*
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
97 containing the exception object type and value, and a reference to the exception
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
98 table for the current function. The personality function for the current
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
99 compile unit is specified in a *common exception frame*.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
100
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
101 The organization of an exception table is language dependent. For C++, an
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
102 exception table is organized as a series of code ranges defining what to do if
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
103 an exception occurs in that range. Typically, the information associated with a
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
104 range defines which types of exception objects (using C++ *type info*) that are
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
105 handled in that range, and an associated action that should take place. Actions
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
106 typically pass control to a *landing pad*.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
107
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
108 A landing pad corresponds roughly to the code found in the ``catch`` portion of
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
109 a ``try``/``catch`` sequence. When execution resumes at a landing pad, it
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
110 receives an *exception structure* and a *selector value* corresponding to the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
111 *type* of exception thrown. The selector is then used to determine which *catch*
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
112 should actually process the exception.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
113
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
114 LLVM Code Generation
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
115 ====================
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
116
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
117 From a C++ developer's perspective, exceptions are defined in terms of the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
118 ``throw`` and ``try``/``catch`` statements. In this section we will describe the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
119 implementation of LLVM exception handling in terms of C++ examples.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
120
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
121 Throw
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
122 -----
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
123
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
124 Languages that support exception handling typically provide a ``throw``
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
125 operation to initiate the exception process. Internally, a ``throw`` operation
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
126 breaks down into two steps.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
127
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
128 #. A request is made to allocate exception space for an exception structure.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
129 This structure needs to survive beyond the current activation. This structure
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
130 will contain the type and value of the object being thrown.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
131
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
132 #. A call is made to the runtime to raise the exception, passing the exception
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
133 structure as an argument.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
134
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
135 In C++, the allocation of the exception structure is done by the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
136 ``__cxa_allocate_exception`` runtime function. The exception raising is handled
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
137 by ``__cxa_throw``. The type of the exception is represented using a C++ RTTI
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
138 structure.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
139
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
140 Try/Catch
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
141 ---------
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
142
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
143 A call within the scope of a *try* statement can potentially raise an
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
144 exception. In those circumstances, the LLVM C++ front-end replaces the call with
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
145 an ``invoke`` instruction. Unlike a call, the ``invoke`` has two potential
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
146 continuation points:
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
147
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
148 #. where to continue when the call succeeds as per normal, and
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
149
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
150 #. where to continue if the call raises an exception, either by a throw or the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
151 unwinding of a throw
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
152
|
|
77
|
153 The term used to define the place where an ``invoke`` continues after an
|
0
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
154 exception is called a *landing pad*. LLVM landing pads are conceptually
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
155 alternative function entry points where an exception structure reference and a
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
156 type info index are passed in as arguments. The landing pad saves the exception
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
157 structure reference and then proceeds to select the catch block that corresponds
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
158 to the type info of the exception object.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
159
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
160 The LLVM :ref:`i_landingpad` is used to convey information about the landing
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
161 pad to the back end. For C++, the ``landingpad`` instruction returns a pointer
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
162 and integer pair corresponding to the pointer to the *exception structure* and
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
163 the *selector value* respectively.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
164
|
|
95
|
165 The ``landingpad`` instruction looks for a reference to the personality
|
|
|
166 function to be used for this ``try``/``catch`` sequence in the parent
|
|
|
167 function's attribute list. The instruction contains a list of *cleanup*,
|
|
|
168 *catch*, and *filter* clauses. The exception is tested against the clauses
|
|
|
169 sequentially from first to last. The clauses have the following meanings:
|
|
77
|
170
|
|
|
171 - ``catch <type> @ExcType``
|
|
|
172
|
|
|
173 - This clause means that the landingpad block should be entered if the
|
|
|
174 exception being thrown is of type ``@ExcType`` or a subtype of
|
|
|
175 ``@ExcType``. For C++, ``@ExcType`` is a pointer to the ``std::type_info``
|
|
|
176 object (an RTTI object) representing the C++ exception type.
|
|
|
177
|
|
|
178 - If ``@ExcType`` is ``null``, any exception matches, so the landingpad
|
|
|
179 should always be entered. This is used for C++ catch-all blocks ("``catch
|
|
|
180 (...)``").
|
|
|
181
|
|
|
182 - When this clause is matched, the selector value will be equal to the value
|
|
|
183 returned by "``@llvm.eh.typeid.for(i8* @ExcType)``". This will always be a
|
|
|
184 positive value.
|
|
|
185
|
|
|
186 - ``filter <type> [<type> @ExcType1, ..., <type> @ExcTypeN]``
|
|
|
187
|
|
|
188 - This clause means that the landingpad should be entered if the exception
|
|
|
189 being thrown does *not* match any of the types in the list (which, for C++,
|
|
|
190 are again specified as ``std::type_info`` pointers).
|
|
|
191
|
|
|
192 - C++ front-ends use this to implement C++ exception specifications, such as
|
|
|
193 "``void foo() throw (ExcType1, ..., ExcTypeN) { ... }``".
|
|
|
194
|
|
|
195 - When this clause is matched, the selector value will be negative.
|
|
|
196
|
|
|
197 - The array argument to ``filter`` may be empty; for example, "``[0 x i8**]
|
|
|
198 undef``". This means that the landingpad should always be entered. (Note
|
|
|
199 that such a ``filter`` would not be equivalent to "``catch i8* null``",
|
|
|
200 because ``filter`` and ``catch`` produce negative and positive selector
|
|
|
201 values respectively.)
|
|
|
202
|
|
|
203 - ``cleanup``
|
|
|
204
|
|
|
205 - This clause means that the landingpad should always be entered.
|
|
|
206
|
|
|
207 - C++ front-ends use this for calling objects' destructors.
|
|
|
208
|
|
|
209 - When this clause is matched, the selector value will be zero.
|
|
|
210
|
|
|
211 - The runtime may treat "``cleanup``" differently from "``catch <type>
|
|
|
212 null``".
|
|
|
213
|
|
|
214 In C++, if an unhandled exception occurs, the language runtime will call
|
|
|
215 ``std::terminate()``, but it is implementation-defined whether the runtime
|
|
|
216 unwinds the stack and calls object destructors first. For example, the GNU
|
|
|
217 C++ unwinder does not call object destructors when an unhandled exception
|
|
|
218 occurs. The reason for this is to improve debuggability: it ensures that
|
|
|
219 ``std::terminate()`` is called from the context of the ``throw``, so that
|
|
|
220 this context is not lost by unwinding the stack. A runtime will typically
|
|
|
221 implement this by searching for a matching non-``cleanup`` clause, and
|
|
|
222 aborting if it does not find one, before entering any landingpad blocks.
|
0
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
223
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
224 Once the landing pad has the type info selector, the code branches to the code
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
225 for the first catch. The catch then checks the value of the type info selector
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
226 against the index of type info for that catch. Since the type info index is not
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
227 known until all the type infos have been gathered in the backend, the catch code
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
228 must call the `llvm.eh.typeid.for`_ intrinsic to determine the index for a given
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
229 type info. If the catch fails to match the selector then control is passed on to
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
230 the next catch.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
231
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
232 Finally, the entry and exit of catch code is bracketed with calls to
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
233 ``__cxa_begin_catch`` and ``__cxa_end_catch``.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
234
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
235 * ``__cxa_begin_catch`` takes an exception structure reference as an argument
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
236 and returns the value of the exception object.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
237
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
238 * ``__cxa_end_catch`` takes no arguments. This function:
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
239
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
240 #. Locates the most recently caught exception and decrements its handler
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
241 count,
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
242
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
243 #. Removes the exception from the *caught* stack if the handler count goes to
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
244 zero, and
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
245
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
246 #. Destroys the exception if the handler count goes to zero and the exception
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
247 was not re-thrown by throw.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
248
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
249 .. note::
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
250
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
251 a rethrow from within the catch may replace this call with a
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
252 ``__cxa_rethrow``.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
253
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
254 Cleanups
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
255 --------
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
256
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
257 A cleanup is extra code which needs to be run as part of unwinding a scope. C++
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
258 destructors are a typical example, but other languages and language extensions
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
259 provide a variety of different kinds of cleanups. In general, a landing pad may
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
260 need to run arbitrary amounts of cleanup code before actually entering a catch
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
261 block. To indicate the presence of cleanups, a :ref:`i_landingpad` should have
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
262 a *cleanup* clause. Otherwise, the unwinder will not stop at the landing pad if
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
263 there are no catches or filters that require it to.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
264
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
265 .. note::
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
266
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
267 Do not allow a new exception to propagate out of the execution of a
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
268 cleanup. This can corrupt the internal state of the unwinder. Different
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
269 languages describe different high-level semantics for these situations: for
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
270 example, C++ requires that the process be terminated, whereas Ada cancels both
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
271 exceptions and throws a third.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
272
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
273 When all cleanups are finished, if the exception is not handled by the current
|
|
95
|
274 function, resume unwinding by calling the :ref:`resume instruction <i_resume>`,
|
|
|
275 passing in the result of the ``landingpad`` instruction for the original
|
|
|
276 landing pad.
|
0
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
277
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
278 Throw Filters
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
279 -------------
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
280
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
281 C++ allows the specification of which exception types may be thrown from a
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
282 function. To represent this, a top level landing pad may exist to filter out
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
283 invalid types. To express this in LLVM code the :ref:`i_landingpad` will have a
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
284 filter clause. The clause consists of an array of type infos.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
285 ``landingpad`` will return a negative value
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
286 if the exception does not match any of the type infos. If no match is found then
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
287 a call to ``__cxa_call_unexpected`` should be made, otherwise
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
288 ``_Unwind_Resume``. Each of these functions requires a reference to the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
289 exception structure. Note that the most general form of a ``landingpad``
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
290 instruction can have any number of catch, cleanup, and filter clauses (though
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
291 having more than one cleanup is pointless). The LLVM C++ front-end can generate
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
292 such ``landingpad`` instructions due to inlining creating nested exception
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
293 handling scopes.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
294
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
295 .. _undefined:
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
296
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
297 Restrictions
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
298 ------------
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
299
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
300 The unwinder delegates the decision of whether to stop in a call frame to that
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
301 call frame's language-specific personality function. Not all unwinders guarantee
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
302 that they will stop to perform cleanups. For example, the GNU C++ unwinder
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
303 doesn't do so unless the exception is actually caught somewhere further up the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
304 stack.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
305
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
306 In order for inlining to behave correctly, landing pads must be prepared to
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
307 handle selector results that they did not originally advertise. Suppose that a
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
308 function catches exceptions of type ``A``, and it's inlined into a function that
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
309 catches exceptions of type ``B``. The inliner will update the ``landingpad``
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
310 instruction for the inlined landing pad to include the fact that ``B`` is also
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
311 caught. If that landing pad assumes that it will only be entered to catch an
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
312 ``A``, it's in for a rude awakening. Consequently, landing pads must test for
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
313 the selector results they understand and then resume exception propagation with
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
314 the `resume instruction <LangRef.html#i_resume>`_ if none of the conditions
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
315 match.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
316
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
317 Exception Handling Intrinsics
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
318 =============================
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
319
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
320 In addition to the ``landingpad`` and ``resume`` instructions, LLVM uses several
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
321 intrinsic functions (name prefixed with ``llvm.eh``) to provide exception
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
322 handling information at various points in generated code.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
323
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
324 .. _llvm.eh.typeid.for:
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
325
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
326 ``llvm.eh.typeid.for``
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
327 ----------------------
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
328
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
329 .. code-block:: llvm
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
330
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
331 i32 @llvm.eh.typeid.for(i8* %type_info)
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
332
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
333
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
334 This intrinsic returns the type info index in the exception table of the current
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
335 function. This value can be used to compare against the result of
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
336 ``landingpad`` instruction. The single argument is a reference to a type info.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
337
|
|
77
|
338 Uses of this intrinsic are generated by the C++ front-end.
|
|
|
339
|
|
83
|
340 .. _llvm.eh.begincatch:
|
|
|
341
|
|
|
342 ``llvm.eh.begincatch``
|
|
|
343 ----------------------
|
|
|
344
|
|
|
345 .. code-block:: llvm
|
|
|
346
|
|
95
|
347 void @llvm.eh.begincatch(i8* %ehptr, i8* %ehobj)
|
|
83
|
348
|
|
|
349
|
|
|
350 This intrinsic marks the beginning of catch handling code within the blocks
|
|
|
351 following a ``landingpad`` instruction. The exact behavior of this function
|
|
|
352 depends on the compilation target and the personality function associated
|
|
|
353 with the ``landingpad`` instruction.
|
|
|
354
|
|
95
|
355 The first argument to this intrinsic is a pointer that was previously extracted
|
|
|
356 from the aggregate return value of the ``landingpad`` instruction. The second
|
|
|
357 argument to the intrinsic is a pointer to stack space where the exception object
|
|
|
358 should be stored. The runtime handles the details of copying the exception
|
|
|
359 object into the slot. If the second parameter is null, no copy occurs.
|
|
83
|
360
|
|
|
361 Uses of this intrinsic are generated by the C++ front-end. Many targets will
|
|
|
362 use implementation-specific functions (such as ``__cxa_begin_catch``) instead
|
|
|
363 of this intrinsic. The intrinsic is provided for targets that require a more
|
|
|
364 abstract interface.
|
|
|
365
|
|
|
366 When used in the native Windows C++ exception handling implementation, this
|
|
|
367 intrinsic serves as a placeholder to delimit code before a catch handler is
|
|
|
368 outlined. When the handler is is outlined, this intrinsic will be replaced
|
|
|
369 by instructions that retrieve the exception object pointer from the frame
|
|
|
370 allocation block.
|
|
|
371
|
|
|
372
|
|
|
373 .. _llvm.eh.endcatch:
|
|
|
374
|
|
|
375 ``llvm.eh.endcatch``
|
|
|
376 ----------------------
|
|
|
377
|
|
|
378 .. code-block:: llvm
|
|
|
379
|
|
|
380 void @llvm.eh.endcatch()
|
|
|
381
|
|
|
382
|
|
|
383 This intrinsic marks the end of catch handling code within the current block,
|
|
|
384 which will be a successor of a block which called ``llvm.eh.begincatch''.
|
|
|
385 The exact behavior of this function depends on the compilation target and the
|
|
|
386 personality function associated with the corresponding ``landingpad``
|
|
|
387 instruction.
|
|
|
388
|
|
|
389 There may be more than one call to ``llvm.eh.endcatch`` for any given call to
|
|
|
390 ``llvm.eh.begincatch`` with each ``llvm.eh.endcatch`` call corresponding to the
|
|
|
391 end of a different control path. All control paths following a call to
|
|
|
392 ``llvm.eh.begincatch`` must reach a call to ``llvm.eh.endcatch``.
|
|
|
393
|
|
|
394 Uses of this intrinsic are generated by the C++ front-end. Many targets will
|
|
|
395 use implementation-specific functions (such as ``__cxa_begin_catch``) instead
|
|
|
396 of this intrinsic. The intrinsic is provided for targets that require a more
|
|
|
397 abstract interface.
|
|
|
398
|
|
|
399 When used in the native Windows C++ exception handling implementation, this
|
|
|
400 intrinsic serves as a placeholder to delimit code before a catch handler is
|
|
|
401 outlined. After the handler is outlined, this intrinsic is simply removed.
|
|
|
402
|
|
|
403
|
|
95
|
404 .. _llvm.eh.exceptionpointer:
|
|
|
405
|
|
|
406 ``llvm.eh.exceptionpointer``
|
|
|
407 ----------------------------
|
|
|
408
|
|
|
409 .. code-block:: llvm
|
|
|
410
|
|
|
411 i8 addrspace(N)* @llvm.eh.padparam.pNi8(token %catchpad)
|
|
|
412
|
|
|
413
|
|
|
414 This intrinsic retrieves a pointer to the exception caught by the given
|
|
|
415 ``catchpad``.
|
|
|
416
|
|
|
417
|
|
77
|
418 SJLJ Intrinsics
|
|
|
419 ---------------
|
|
|
420
|
|
|
421 The ``llvm.eh.sjlj`` intrinsics are used internally within LLVM's
|
|
|
422 backend. Uses of them are generated by the backend's
|
|
|
423 ``SjLjEHPrepare`` pass.
|
|
|
424
|
0
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
425 .. _llvm.eh.sjlj.setjmp:
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
426
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
427 ``llvm.eh.sjlj.setjmp``
|
|
77
|
428 ~~~~~~~~~~~~~~~~~~~~~~~
|
0
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
429
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
430 .. code-block:: llvm
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
431
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
432 i32 @llvm.eh.sjlj.setjmp(i8* %setjmp_buf)
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
433
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
434 For SJLJ based exception handling, this intrinsic forces register saving for the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
435 current function and stores the address of the following instruction for use as
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
436 a destination address by `llvm.eh.sjlj.longjmp`_. The buffer format and the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
437 overall functioning of this intrinsic is compatible with the GCC
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
438 ``__builtin_setjmp`` implementation allowing code built with the clang and GCC
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
439 to interoperate.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
440
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
441 The single parameter is a pointer to a five word buffer in which the calling
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
442 context is saved. The front end places the frame pointer in the first word, and
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
443 the target implementation of this intrinsic should place the destination address
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
444 for a `llvm.eh.sjlj.longjmp`_ in the second word. The following three words are
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
445 available for use in a target-specific manner.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
446
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
447 .. _llvm.eh.sjlj.longjmp:
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
448
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
449 ``llvm.eh.sjlj.longjmp``
|
|
77
|
450 ~~~~~~~~~~~~~~~~~~~~~~~~
|
0
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
451
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
452 .. code-block:: llvm
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
453
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
454 void @llvm.eh.sjlj.longjmp(i8* %setjmp_buf)
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
455
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
456 For SJLJ based exception handling, the ``llvm.eh.sjlj.longjmp`` intrinsic is
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
457 used to implement ``__builtin_longjmp()``. The single parameter is a pointer to
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
458 a buffer populated by `llvm.eh.sjlj.setjmp`_. The frame pointer and stack
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
459 pointer are restored from the buffer, then control is transferred to the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
460 destination address.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
461
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
462 ``llvm.eh.sjlj.lsda``
|
|
77
|
463 ~~~~~~~~~~~~~~~~~~~~~
|
0
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
464
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
465 .. code-block:: llvm
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
466
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
467 i8* @llvm.eh.sjlj.lsda()
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
468
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
469 For SJLJ based exception handling, the ``llvm.eh.sjlj.lsda`` intrinsic returns
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
470 the address of the Language Specific Data Area (LSDA) for the current
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
471 function. The SJLJ front-end code stores this address in the exception handling
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
472 function context for use by the runtime.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
473
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
474 ``llvm.eh.sjlj.callsite``
|
|
77
|
475 ~~~~~~~~~~~~~~~~~~~~~~~~~
|
0
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
476
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
477 .. code-block:: llvm
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
478
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
479 void @llvm.eh.sjlj.callsite(i32 %call_site_num)
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
480
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
481 For SJLJ based exception handling, the ``llvm.eh.sjlj.callsite`` intrinsic
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
482 identifies the callsite value associated with the following ``invoke``
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
483 instruction. This is used to ensure that landing pad entries in the LSDA are
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
484 generated in matching order.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
485
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
486 Asm Table Formats
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
487 =================
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
488
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
489 There are two tables that are used by the exception handling runtime to
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
490 determine which actions should be taken when an exception is thrown.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
491
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
492 Exception Handling Frame
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
493 ------------------------
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
494
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
495 An exception handling frame ``eh_frame`` is very similar to the unwind frame
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
496 used by DWARF debug info. The frame contains all the information necessary to
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
497 tear down the current frame and restore the state of the prior frame. There is
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
498 an exception handling frame for each function in a compile unit, plus a common
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
499 exception handling frame that defines information common to all functions in the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
500 unit.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
501
|
|
95
|
502 The format of this call frame information (CFI) is often platform-dependent,
|
|
|
503 however. ARM, for example, defines their own format. Apple has their own compact
|
|
|
504 unwind info format. On Windows, another format is used for all architectures
|
|
|
505 since 32-bit x86. LLVM will emit whatever information is required by the
|
|
|
506 target.
|
|
|
507
|
0
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
508 Exception Tables
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
509 ----------------
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
510
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
511 An exception table contains information about what actions to take when an
|
|
95
|
512 exception is thrown in a particular part of a function's code. This is typically
|
|
|
513 referred to as the language-specific data area (LSDA). The format of the LSDA
|
|
|
514 table is specific to the personality function, but the majority of personalities
|
|
|
515 out there use a variation of the tables consumed by ``__gxx_personality_v0``.
|
|
|
516 There is one exception table per function, except leaf functions and functions
|
|
|
517 that have calls only to non-throwing functions. They do not need an exception
|
|
|
518 table.
|
|
|
519
|
|
|
520 .. _wineh:
|
|
|
521
|
|
|
522 Exception Handling using the Windows Runtime
|
|
|
523 =================================================
|
|
|
524
|
|
|
525 Background on Windows exceptions
|
|
|
526 ---------------------------------
|
|
|
527
|
|
100
|
528 Interacting with exceptions on Windows is significantly more complicated than
|
|
|
529 on Itanium C++ ABI platforms. The fundamental difference between the two models
|
|
|
530 is that Itanium EH is designed around the idea of "successive unwinding," while
|
|
95
|
531 Windows EH is not.
|
|
|
532
|
|
|
533 Under Itanium, throwing an exception typically involes allocating thread local
|
|
|
534 memory to hold the exception, and calling into the EH runtime. The runtime
|
|
|
535 identifies frames with appropriate exception handling actions, and successively
|
|
|
536 resets the register context of the current thread to the most recently active
|
|
|
537 frame with actions to run. In LLVM, execution resumes at a ``landingpad``
|
|
|
538 instruction, which produces register values provided by the runtime. If a
|
|
|
539 function is only cleaning up allocated resources, the function is responsible
|
|
|
540 for calling ``_Unwind_Resume`` to transition to the next most recently active
|
|
|
541 frame after it is finished cleaning up. Eventually, the frame responsible for
|
|
|
542 handling the exception calls ``__cxa_end_catch`` to destroy the exception,
|
|
|
543 release its memory, and resume normal control flow.
|
|
|
544
|
|
|
545 The Windows EH model does not use these successive register context resets.
|
|
|
546 Instead, the active exception is typically described by a frame on the stack.
|
|
|
547 In the case of C++ exceptions, the exception object is allocated in stack memory
|
|
|
548 and its address is passed to ``__CxxThrowException``. General purpose structured
|
|
|
549 exceptions (SEH) are more analogous to Linux signals, and they are dispatched by
|
|
|
550 userspace DLLs provided with Windows. Each frame on the stack has an assigned EH
|
|
|
551 personality routine, which decides what actions to take to handle the exception.
|
|
|
552 There are a few major personalities for C and C++ code: the C++ personality
|
|
|
553 (``__CxxFrameHandler3``) and the SEH personalities (``_except_handler3``,
|
|
|
554 ``_except_handler4``, and ``__C_specific_handler``). All of them implement
|
|
|
555 cleanups by calling back into a "funclet" contained in the parent function.
|
|
|
556
|
|
|
557 Funclets, in this context, are regions of the parent function that can be called
|
|
|
558 as though they were a function pointer with a very special calling convention.
|
|
|
559 The frame pointer of the parent frame is passed into the funclet either using
|
|
|
560 the standard EBP register or as the first parameter register, depending on the
|
|
|
561 architecture. The funclet implements the EH action by accessing local variables
|
|
|
562 in memory through the frame pointer, and returning some appropriate value,
|
|
|
563 continuing the EH process. No variables live in to or out of the funclet can be
|
|
|
564 allocated in registers.
|
|
|
565
|
|
|
566 The C++ personality also uses funclets to contain the code for catch blocks
|
|
|
567 (i.e. all user code between the braces in ``catch (Type obj) { ... }``). The
|
|
|
568 runtime must use funclets for catch bodies because the C++ exception object is
|
|
|
569 allocated in a child stack frame of the function handling the exception. If the
|
|
|
570 runtime rewound the stack back to frame of the catch, the memory holding the
|
|
|
571 exception would be overwritten quickly by subsequent function calls. The use of
|
|
|
572 funclets also allows ``__CxxFrameHandler3`` to implement rethrow without
|
|
|
573 resorting to TLS. Instead, the runtime throws a special exception, and then uses
|
|
|
574 SEH (``__try / __except``) to resume execution with new information in the child
|
|
|
575 frame.
|
|
|
576
|
|
|
577 In other words, the successive unwinding approach is incompatible with Visual
|
|
|
578 C++ exceptions and general purpose Windows exception handling. Because the C++
|
|
|
579 exception object lives in stack memory, LLVM cannot provide a custom personality
|
|
|
580 function that uses landingpads. Similarly, SEH does not provide any mechanism
|
|
|
581 to rethrow an exception or continue unwinding. Therefore, LLVM must use the IR
|
|
|
582 constructs described later in this document to implement compatible exception
|
|
|
583 handling.
|
|
|
584
|
|
|
585 SEH filter expressions
|
|
|
586 -----------------------
|
|
|
587
|
|
|
588 The SEH personality functions also use funclets to implement filter expressions,
|
|
|
589 which allow executing arbitrary user code to decide which exceptions to catch.
|
|
|
590 Filter expressions should not be confused with the ``filter`` clause of the LLVM
|
|
|
591 ``landingpad`` instruction. Typically filter expressions are used to determine
|
|
|
592 if the exception came from a particular DLL or code region, or if code faulted
|
|
|
593 while accessing a particular memory address range. LLVM does not currently have
|
|
|
594 IR to represent filter expressions because it is difficult to represent their
|
|
|
595 control dependencies. Filter expressions run during the first phase of EH,
|
|
|
596 before cleanups run, making it very difficult to build a faithful control flow
|
|
|
597 graph. For now, the new EH instructions cannot represent SEH filter
|
|
|
598 expressions, and frontends must outline them ahead of time. Local variables of
|
|
|
599 the parent function can be escaped and accessed using the ``llvm.localescape``
|
|
|
600 and ``llvm.localrecover`` intrinsics.
|
|
|
601
|
|
|
602 New exception handling instructions
|
|
|
603 ------------------------------------
|
|
|
604
|
|
|
605 The primary design goal of the new EH instructions is to support funclet
|
|
|
606 generation while preserving information about the CFG so that SSA formation
|
|
|
607 still works. As a secondary goal, they are designed to be generic across MSVC
|
|
|
608 and Itanium C++ exceptions. They make very few assumptions about the data
|
|
|
609 required by the personality, so long as it uses the familiar core EH actions:
|
|
|
610 catch, cleanup, and terminate. However, the new instructions are hard to modify
|
|
|
611 without knowing details of the EH personality. While they can be used to
|
|
|
612 represent Itanium EH, the landingpad model is strictly better for optimization
|
|
|
613 purposes.
|
|
|
614
|
|
|
615 The following new instructions are considered "exception handling pads", in that
|
|
|
616 they must be the first non-phi instruction of a basic block that may be the
|
|
100
|
617 unwind destination of an EH flow edge:
|
|
|
618 ``catchswitch``, ``catchpad``, and ``cleanuppad``.
|
|
|
619 As with landingpads, when entering a try scope, if the
|
|
95
|
620 frontend encounters a call site that may throw an exception, it should emit an
|
|
100
|
621 invoke that unwinds to a ``catchswitch`` block. Similarly, inside the scope of a
|
|
|
622 C++ object with a destructor, invokes should unwind to a ``cleanuppad``.
|
|
95
|
623
|
|
|
624 New instructions are also used to mark the points where control is transferred
|
|
|
625 out of a catch/cleanup handler (which will correspond to exits from the
|
|
|
626 generated funclet). A catch handler which reaches its end by normal execution
|
|
|
627 executes a ``catchret`` instruction, which is a terminator indicating where in
|
|
|
628 the function control is returned to. A cleanup handler which reaches its end
|
|
|
629 by normal execution executes a ``cleanupret`` instruction, which is a terminator
|
|
100
|
630 indicating where the active exception will unwind to next.
|
|
95
|
631
|
|
100
|
632 Each of these new EH pad instructions has a way to identify which action should
|
|
|
633 be considered after this action. The ``catchswitch`` instruction is a terminator
|
|
|
634 and has an unwind destination operand analogous to the unwind destination of an
|
|
|
635 invoke. The ``cleanuppad`` instruction is not
|
|
|
636 a terminator, so the unwind destination is stored on the ``cleanupret``
|
|
|
637 instruction instead. Successfully executing a catch handler should resume
|
|
|
638 normal control flow, so neither ``catchpad`` nor ``catchret`` instructions can
|
|
|
639 unwind. All of these "unwind edges" may refer to a basic block that contains an
|
|
|
640 EH pad instruction, or they may unwind to the caller. Unwinding to the caller
|
|
|
641 has roughly the same semantics as the ``resume`` instruction in the landingpad
|
|
|
642 model. When inlining through an invoke, instructions that unwind to the caller
|
|
|
643 are hooked up to unwind to the unwind destination of the call site.
|
|
95
|
644
|
|
|
645 Putting things together, here is a hypothetical lowering of some C++ that uses
|
|
|
646 all of the new IR instructions:
|
|
|
647
|
|
|
648 .. code-block:: c
|
|
|
649
|
|
|
650 struct Cleanup {
|
|
|
651 Cleanup();
|
|
|
652 ~Cleanup();
|
|
|
653 int m;
|
|
|
654 };
|
|
|
655 void may_throw();
|
|
|
656 int f() noexcept {
|
|
|
657 try {
|
|
|
658 Cleanup obj;
|
|
|
659 may_throw();
|
|
|
660 } catch (int e) {
|
|
|
661 may_throw();
|
|
|
662 return e;
|
|
|
663 }
|
|
|
664 return 0;
|
|
|
665 }
|
|
|
666
|
|
|
667 .. code-block:: llvm
|
|
|
668
|
|
|
669 define i32 @f() nounwind personality i32 (...)* @__CxxFrameHandler3 {
|
|
|
670 entry:
|
|
|
671 %obj = alloca %struct.Cleanup, align 4
|
|
|
672 %e = alloca i32, align 4
|
|
|
673 %call = invoke %struct.Cleanup* @"\01??0Cleanup@@QEAA@XZ"(%struct.Cleanup* nonnull %obj)
|
|
|
674 to label %invoke.cont unwind label %lpad.catch
|
|
|
675
|
|
|
676 invoke.cont: ; preds = %entry
|
|
|
677 invoke void @"\01?may_throw@@YAXXZ"()
|
|
|
678 to label %invoke.cont.2 unwind label %lpad.cleanup
|
|
|
679
|
|
|
680 invoke.cont.2: ; preds = %invoke.cont
|
|
|
681 call void @"\01??_DCleanup@@QEAA@XZ"(%struct.Cleanup* nonnull %obj) nounwind
|
|
|
682 br label %return
|
|
|
683
|
|
100
|
684 return: ; preds = %invoke.cont.3, %invoke.cont.2
|
|
|
685 %retval.0 = phi i32 [ 0, %invoke.cont.2 ], [ %3, %invoke.cont.3 ]
|
|
95
|
686 ret i32 %retval.0
|
|
|
687
|
|
100
|
688 lpad.cleanup: ; preds = %invoke.cont.2
|
|
|
689 %0 = cleanuppad within none []
|
|
|
690 call void @"\01??1Cleanup@@QEAA@XZ"(%struct.Cleanup* nonnull %obj) nounwind
|
|
|
691 cleanupret %0 unwind label %lpad.catch
|
|
95
|
692
|
|
100
|
693 lpad.catch: ; preds = %lpad.cleanup, %entry
|
|
|
694 %1 = catchswitch within none [label %catch.body] unwind label %lpad.terminate
|
|
95
|
695
|
|
|
696 catch.body: ; preds = %lpad.catch
|
|
100
|
697 %catch = catchpad within %1 [%rtti.TypeDescriptor2* @"\01??_R0H@8", i32 0, i32* %e]
|
|
95
|
698 invoke void @"\01?may_throw@@YAXXZ"()
|
|
100
|
699 to label %invoke.cont.3 unwind label %lpad.terminate
|
|
95
|
700
|
|
|
701 invoke.cont.3: ; preds = %catch.body
|
|
100
|
702 %3 = load i32, i32* %e, align 4
|
|
|
703 catchret from %catch to label %return
|
|
|
704
|
|
|
705 lpad.terminate: ; preds = %catch.body, %lpad.catch
|
|
|
706 cleanuppad within none []
|
|
|
707 call void @"\01?terminate@@YAXXZ"
|
|
|
708 unreachable
|
|
|
709 }
|
|
|
710
|
|
|
711 Funclet parent tokens
|
|
|
712 -----------------------
|
|
|
713
|
|
|
714 In order to produce tables for EH personalities that use funclets, it is
|
|
|
715 necessary to recover the nesting that was present in the source. This funclet
|
|
|
716 parent relationship is encoded in the IR using tokens produced by the new "pad"
|
|
|
717 instructions. The token operand of a "pad" or "ret" instruction indicates which
|
|
|
718 funclet it is in, or "none" if it is not nested within another funclet.
|
|
|
719
|
|
|
720 The ``catchpad`` and ``cleanuppad`` instructions establish new funclets, and
|
|
|
721 their tokens are consumed by other "pad" instructions to establish membership.
|
|
|
722 The ``catchswitch`` instruction does not create a funclet, but it produces a
|
|
|
723 token that is always consumed by its immediate successor ``catchpad``
|
|
|
724 instructions. This ensures that every catch handler modelled by a ``catchpad``
|
|
|
725 belongs to exactly one ``catchswitch``, which models the dispatch point after a
|
|
|
726 C++ try.
|
|
|
727
|
|
|
728 Here is an example of what this nesting looks like using some hypothetical
|
|
|
729 C++ code:
|
|
|
730
|
|
|
731 .. code-block:: c
|
|
|
732
|
|
|
733 void f() {
|
|
|
734 try {
|
|
|
735 throw;
|
|
|
736 } catch (...) {
|
|
|
737 try {
|
|
|
738 throw;
|
|
|
739 } catch (...) {
|
|
|
740 }
|
|
|
741 }
|
|
|
742 }
|
|
|
743
|
|
|
744 .. code-block:: llvm
|
|
|
745
|
|
|
746 define void @f() #0 personality i8* bitcast (i32 (...)* @__CxxFrameHandler3 to i8*) {
|
|
|
747 entry:
|
|
|
748 invoke void @_CxxThrowException(i8* null, %eh.ThrowInfo* null) #1
|
|
|
749 to label %unreachable unwind label %catch.dispatch
|
|
|
750
|
|
|
751 catch.dispatch: ; preds = %entry
|
|
|
752 %0 = catchswitch within none [label %catch] unwind to caller
|
|
|
753
|
|
|
754 catch: ; preds = %catch.dispatch
|
|
|
755 %1 = catchpad within %0 [i8* null, i32 64, i8* null]
|
|
|
756 invoke void @_CxxThrowException(i8* null, %eh.ThrowInfo* null) #1
|
|
|
757 to label %unreachable unwind label %catch.dispatch2
|
|
|
758
|
|
|
759 catch.dispatch2: ; preds = %catch
|
|
|
760 %2 = catchswitch within %1 [label %catch3] unwind to caller
|
|
|
761
|
|
|
762 catch3: ; preds = %catch.dispatch2
|
|
|
763 %3 = catchpad within %2 [i8* null, i32 64, i8* null]
|
|
|
764 catchret from %3 to label %try.cont
|
|
|
765
|
|
|
766 try.cont: ; preds = %catch3
|
|
|
767 catchret from %1 to label %try.cont6
|
|
|
768
|
|
|
769 try.cont6: ; preds = %try.cont
|
|
|
770 ret void
|
|
95
|
771
|
|
100
|
772 unreachable: ; preds = %catch, %entry
|
|
|
773 unreachable
|
|
|
774 }
|
|
|
775
|
|
|
776 The "inner" ``catchswitch`` consumes ``%1`` which is produced by the outer
|
|
|
777 catchswitch.
|
|
|
778
|
|
|
779 .. _wineh-constraints:
|
|
|
780
|
|
|
781 Funclet transitions
|
|
|
782 -----------------------
|
|
|
783
|
|
|
784 The EH tables for personalities that use funclets make implicit use of the
|
|
|
785 funclet nesting relationship to encode unwind destinations, and so are
|
|
|
786 constrained in the set of funclet transitions they can represent. The related
|
|
|
787 LLVM IR instructions accordingly have constraints that ensure encodability of
|
|
|
788 the EH edges in the flow graph.
|
|
|
789
|
|
|
790 A ``catchswitch``, ``catchpad``, or ``cleanuppad`` is said to be "entered"
|
|
|
791 when it executes. It may subsequently be "exited" by any of the following
|
|
|
792 means:
|
|
95
|
793
|
|
100
|
794 * A ``catchswitch`` is immediately exited when none of its constituent
|
|
|
795 ``catchpad``\ s are appropriate for the in-flight exception and it unwinds
|
|
|
796 to its unwind destination or the caller.
|
|
|
797 * A ``catchpad`` and its parent ``catchswitch`` are both exited when a
|
|
|
798 ``catchret`` from the ``catchpad`` is executed.
|
|
|
799 * A ``cleanuppad`` is exited when a ``cleanupret`` from it is executed.
|
|
|
800 * Any of these pads is exited when control unwinds to the function's caller,
|
|
|
801 either by a ``call`` which unwinds all the way to the function's caller,
|
|
|
802 a nested ``catchswitch`` marked "``unwinds to caller``", or a nested
|
|
|
803 ``cleanuppad``\ 's ``cleanupret`` marked "``unwinds to caller"``.
|
|
|
804 * Any of these pads is exited when an unwind edge (from an ``invoke``,
|
|
|
805 nested ``catchswitch``, or nested ``cleanuppad``\ 's ``cleanupret``)
|
|
|
806 unwinds to a destination pad that is not a descendant of the given pad.
|
|
|
807
|
|
|
808 Note that the ``ret`` instruction is *not* a valid way to exit a funclet pad;
|
|
|
809 it is undefined behavior to execute a ``ret`` when a pad has been entered but
|
|
|
810 not exited.
|
|
|
811
|
|
|
812 A single unwind edge may exit any number of pads (with the restrictions that
|
|
|
813 the edge from a ``catchswitch`` must exit at least itself, and the edge from
|
|
|
814 a ``cleanupret`` must exit at least its ``cleanuppad``), and then must enter
|
|
|
815 exactly one pad, which must be distinct from all the exited pads. The parent
|
|
|
816 of the pad that an unwind edge enters must be the most-recently-entered
|
|
|
817 not-yet-exited pad (after exiting from any pads that the unwind edge exits),
|
|
|
818 or "none" if there is no such pad. This ensures that the stack of executing
|
|
|
819 funclets at run-time always corresponds to some path in the funclet pad tree
|
|
|
820 that the parent tokens encode.
|
|
|
821
|
|
|
822 All unwind edges which exit any given funclet pad (including ``cleanupret``
|
|
|
823 edges exiting their ``cleanuppad`` and ``catchswitch`` edges exiting their
|
|
|
824 ``catchswitch``) must share the same unwind destination. Similarly, any
|
|
|
825 funclet pad which may be exited by unwind to caller must not be exited by
|
|
|
826 any exception edges which unwind anywhere other than the caller. This
|
|
|
827 ensures that each funclet as a whole has only one unwind destination, which
|
|
|
828 EH tables for funclet personalities may require. Note that any unwind edge
|
|
|
829 which exits a ``catchpad`` also exits its parent ``catchswitch``, so this
|
|
|
830 implies that for any given ``catchswitch``, its unwind destination must also
|
|
|
831 be the unwind destination of any unwind edge that exits any of its constituent
|
|
|
832 ``catchpad``\s. Because ``catchswitch`` has no ``nounwind`` variant, and
|
|
|
833 because IR producers are not *required* to annotate calls which will not
|
|
|
834 unwind as ``nounwind``, it is legal to nest a ``call`` or an "``unwind to
|
|
|
835 caller``\ " ``catchswitch`` within a funclet pad that has an unwind
|
|
|
836 destination other than caller; it is undefined behavior for such a ``call``
|
|
|
837 or ``catchswitch`` to unwind.
|
|
|
838
|
|
|
839 Finally, the funclet pads' unwind destinations cannot form a cycle. This
|
|
|
840 ensures that EH lowering can construct "try regions" with a tree-like
|
|
|
841 structure, which funclet-based personalities may require.
|
