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
|
|
70 Windows runtime based exception handling uses the same basic IR structure as
|
|
71 Itanium ABI based exception handling, but it relies on the personality
|
|
72 functions provided by the native Windows runtime library, ``__CxxFrameHandler3``
|
|
73 for C++ exceptions: ``__C_specific_handler`` for 64-bit SEH or
|
|
74 ``_frame_handler3/4`` for 32-bit SEH. This results in a very different
|
|
75 execution model and requires some minor modifications to the initial IR
|
|
76 representation and a significant restructuring just before code generation.
|
|
77
|
|
78 General information about the Windows x64 exception handling mechanism can be
|
|
79 found at `MSDN Exception Handling (x64)
|
|
80 <https://msdn.microsoft.com/en-us/library/1eyas8tf(v=vs.80).aspx>_`.
|
|
81
|
0
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
82 Overview
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
83 --------
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
84
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
85 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
|
86 handler suited to processing the circumstance.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
87
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
88 The runtime first attempts to find an *exception frame* corresponding to the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
89 function where the exception was thrown. If the programming language supports
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
90 exception handling (e.g. C++), the exception frame contains a reference to an
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
91 exception table describing how to process the exception. If the language does
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
92 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
|
93 forwarded to a prior activation, the exception frame contains information about
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
94 how to unwind the current activation and restore the state of the prior
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
95 activation. This process is repeated until the exception is handled. If the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
96 exception is not handled and no activations remain, then the application is
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
97 terminated with an appropriate error message.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
98
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
99 Because different programming languages have different behaviors when handling
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
100 exceptions, the exception handling ABI provides a mechanism for
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
101 supplying *personalities*. An exception handling personality is defined by
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
102 way of a *personality function* (e.g. ``__gxx_personality_v0`` in C++),
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
103 which receives the context of the exception, an *exception structure*
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
104 containing the exception object type and value, and a reference to the exception
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
105 table for the current function. The personality function for the current
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
106 compile unit is specified in a *common exception frame*.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
107
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
108 The organization of an exception table is language dependent. For C++, an
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
109 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
|
110 an exception occurs in that range. Typically, the information associated with a
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
111 range defines which types of exception objects (using C++ *type info*) that are
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
112 handled in that range, and an associated action that should take place. Actions
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
113 typically pass control to a *landing pad*.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
114
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
115 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
|
116 a ``try``/``catch`` sequence. When execution resumes at a landing pad, it
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
117 receives an *exception structure* and a *selector value* corresponding to the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
118 *type* of exception thrown. The selector is then used to determine which *catch*
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
119 should actually process the exception.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
120
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
121 LLVM Code Generation
|
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 From a C++ developer's perspective, exceptions are defined in terms of the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
125 ``throw`` and ``try``/``catch`` statements. In this section we will describe the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
126 implementation of LLVM exception handling in terms of C++ examples.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
127
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
128 Throw
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
129 -----
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
130
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
131 Languages that support exception handling typically provide a ``throw``
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
132 operation to initiate the exception process. Internally, a ``throw`` operation
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
133 breaks down into two steps.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
134
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
135 #. A request is made to allocate exception space for an exception structure.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
136 This structure needs to survive beyond the current activation. This structure
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
137 will contain the type and value of the object being thrown.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
138
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
139 #. 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
|
140 structure as an argument.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
141
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
142 In C++, the allocation of the exception structure is done by the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
143 ``__cxa_allocate_exception`` runtime function. The exception raising is handled
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
144 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
|
145 structure.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
146
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
147 Try/Catch
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
148 ---------
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
149
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
150 A call within the scope of a *try* statement can potentially raise an
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
151 exception. In those circumstances, the LLVM C++ front-end replaces the call with
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
152 an ``invoke`` instruction. Unlike a call, the ``invoke`` has two potential
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
153 continuation points:
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
154
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
155 #. where to continue when the call succeeds as per normal, and
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
156
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
157 #. 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
|
158 unwinding of a throw
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
159
|
77
|
160 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
|
161 exception is called a *landing pad*. LLVM landing pads are conceptually
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
162 alternative function entry points where an exception structure reference and a
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
163 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
|
164 structure reference and then proceeds to select the catch block that corresponds
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
165 to the type info of the exception object.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
166
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
167 The LLVM :ref:`i_landingpad` is used to convey information about the landing
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
168 pad to the back end. For C++, the ``landingpad`` instruction returns a pointer
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
169 and integer pair corresponding to the pointer to the *exception structure* and
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
170 the *selector value* respectively.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
171
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
172 The ``landingpad`` instruction takes a reference to the personality function to
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
173 be used for this ``try``/``catch`` sequence. The remainder of the instruction is
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
174 a list of *cleanup*, *catch*, and *filter* clauses. The exception is tested
|
77
|
175 against the clauses sequentially from first to last. The clauses have the
|
|
176 following meanings:
|
|
177
|
|
178 - ``catch <type> @ExcType``
|
|
179
|
|
180 - This clause means that the landingpad block should be entered if the
|
|
181 exception being thrown is of type ``@ExcType`` or a subtype of
|
|
182 ``@ExcType``. For C++, ``@ExcType`` is a pointer to the ``std::type_info``
|
|
183 object (an RTTI object) representing the C++ exception type.
|
|
184
|
|
185 - If ``@ExcType`` is ``null``, any exception matches, so the landingpad
|
|
186 should always be entered. This is used for C++ catch-all blocks ("``catch
|
|
187 (...)``").
|
|
188
|
|
189 - When this clause is matched, the selector value will be equal to the value
|
|
190 returned by "``@llvm.eh.typeid.for(i8* @ExcType)``". This will always be a
|
|
191 positive value.
|
|
192
|
|
193 - ``filter <type> [<type> @ExcType1, ..., <type> @ExcTypeN]``
|
|
194
|
|
195 - This clause means that the landingpad should be entered if the exception
|
|
196 being thrown does *not* match any of the types in the list (which, for C++,
|
|
197 are again specified as ``std::type_info`` pointers).
|
|
198
|
|
199 - C++ front-ends use this to implement C++ exception specifications, such as
|
|
200 "``void foo() throw (ExcType1, ..., ExcTypeN) { ... }``".
|
|
201
|
|
202 - When this clause is matched, the selector value will be negative.
|
|
203
|
|
204 - The array argument to ``filter`` may be empty; for example, "``[0 x i8**]
|
|
205 undef``". This means that the landingpad should always be entered. (Note
|
|
206 that such a ``filter`` would not be equivalent to "``catch i8* null``",
|
|
207 because ``filter`` and ``catch`` produce negative and positive selector
|
|
208 values respectively.)
|
|
209
|
|
210 - ``cleanup``
|
|
211
|
|
212 - This clause means that the landingpad should always be entered.
|
|
213
|
|
214 - C++ front-ends use this for calling objects' destructors.
|
|
215
|
|
216 - When this clause is matched, the selector value will be zero.
|
|
217
|
|
218 - The runtime may treat "``cleanup``" differently from "``catch <type>
|
|
219 null``".
|
|
220
|
|
221 In C++, if an unhandled exception occurs, the language runtime will call
|
|
222 ``std::terminate()``, but it is implementation-defined whether the runtime
|
|
223 unwinds the stack and calls object destructors first. For example, the GNU
|
|
224 C++ unwinder does not call object destructors when an unhandled exception
|
|
225 occurs. The reason for this is to improve debuggability: it ensures that
|
|
226 ``std::terminate()`` is called from the context of the ``throw``, so that
|
|
227 this context is not lost by unwinding the stack. A runtime will typically
|
|
228 implement this by searching for a matching non-``cleanup`` clause, and
|
|
229 aborting if it does not find one, before entering any landingpad blocks.
|
0
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
230
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
231 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
|
232 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
|
233 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
|
234 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
|
235 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
|
236 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
|
237 the next catch.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
238
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
239 Finally, the entry and exit of catch code is bracketed with calls to
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
240 ``__cxa_begin_catch`` and ``__cxa_end_catch``.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
241
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
242 * ``__cxa_begin_catch`` takes an exception structure reference as an argument
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
243 and returns the value of the exception object.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
244
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
245 * ``__cxa_end_catch`` takes no arguments. This function:
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
246
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
247 #. Locates the most recently caught exception and decrements its handler
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
248 count,
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
249
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
250 #. Removes the exception from the *caught* stack if the handler count goes to
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
251 zero, and
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
252
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
253 #. Destroys the exception if the handler count goes to zero and the exception
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
254 was not re-thrown by throw.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
255
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
256 .. note::
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
257
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
258 a rethrow from within the catch may replace this call with a
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
259 ``__cxa_rethrow``.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
260
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
261 Cleanups
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
262 --------
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
263
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
264 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
|
265 destructors are a typical example, but other languages and language extensions
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
266 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
|
267 need to run arbitrary amounts of cleanup code before actually entering a catch
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
268 block. To indicate the presence of cleanups, a :ref:`i_landingpad` should have
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
269 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
|
270 there are no catches or filters that require it to.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
271
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
272 .. note::
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
273
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
274 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
|
275 cleanup. This can corrupt the internal state of the unwinder. Different
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
276 languages describe different high-level semantics for these situations: for
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
277 example, C++ requires that the process be terminated, whereas Ada cancels both
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
278 exceptions and throws a third.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
279
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
280 When all cleanups are finished, if the exception is not handled by the current
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
281 function, resume unwinding by calling the `resume
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
282 instruction <LangRef.html#i_resume>`_, passing in the result of the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
283 ``landingpad`` instruction for the original landing pad.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
284
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
285 Throw Filters
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
286 -------------
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
287
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
288 C++ allows the specification of which exception types may be thrown from a
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
289 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
|
290 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
|
291 filter clause. The clause consists of an array of type infos.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
292 ``landingpad`` will return a negative value
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
293 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
|
294 a call to ``__cxa_call_unexpected`` should be made, otherwise
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
295 ``_Unwind_Resume``. Each of these functions requires a reference to the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
296 exception structure. Note that the most general form of a ``landingpad``
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
297 instruction can have any number of catch, cleanup, and filter clauses (though
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
298 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
|
299 such ``landingpad`` instructions due to inlining creating nested exception
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
300 handling scopes.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
301
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
302 .. _undefined:
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
303
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
304 Restrictions
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
305 ------------
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
306
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
307 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
|
308 call frame's language-specific personality function. Not all unwinders guarantee
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
309 that they will stop to perform cleanups. For example, the GNU C++ unwinder
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
310 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
|
311 stack.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
312
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
313 In order for inlining to behave correctly, landing pads must be prepared to
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
314 handle selector results that they did not originally advertise. Suppose that a
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
315 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
|
316 catches exceptions of type ``B``. The inliner will update the ``landingpad``
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
317 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
|
318 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
|
319 ``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
|
320 the selector results they understand and then resume exception propagation with
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
321 the `resume instruction <LangRef.html#i_resume>`_ if none of the conditions
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
322 match.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
323
|
83
|
324 C++ Exception Handling using the Windows Runtime
|
|
325 =================================================
|
|
326
|
|
327 (Note: Windows C++ exception handling support is a work in progress and is
|
|
328 not yet fully implemented. The text below describes how it will work
|
|
329 when completed.)
|
|
330
|
|
331 The Windows runtime function for C++ exception handling uses a multi-phase
|
|
332 approach. When an exception occurs it searches the current callstack for a
|
|
333 frame that has a handler for the exception. If a handler is found, it then
|
|
334 calls the cleanup handler for each frame above the handler which has a
|
|
335 cleanup handler before calling the catch handler. These calls are all made
|
|
336 from a stack context different from the original frame in which the handler
|
|
337 is defined. Therefore, it is necessary to outline these handlers from their
|
|
338 original context before code generation.
|
|
339
|
|
340 Catch handlers are called with a pointer to the handler itself as the first
|
|
341 argument and a pointer to the parent function's stack frame as the second
|
|
342 argument. The catch handler uses the `llvm.recoverframe
|
|
343 <LangRef.html#llvm-frameallocate-and-llvm-framerecover-intrinsics>`_ to get a
|
|
344 pointer to a frame allocation block that is created in the parent frame using
|
|
345 the `llvm.allocateframe
|
|
346 <LangRef.html#llvm-frameallocate-and-llvm-framerecover-intrinsics>`_ intrinsic.
|
|
347 The ``WinEHPrepare`` pass will have created a structure definition for the
|
|
348 contents of this block. The first two members of the structure will always be
|
|
349 (1) a 32-bit integer that the runtime uses to track the exception state of the
|
|
350 parent frame for the purposes of handling chained exceptions and (2) a pointer
|
|
351 to the object associated with the exception (roughly, the parameter of the
|
|
352 catch clause). These two members will be followed by any frame variables from
|
|
353 the parent function which must be accessed in any of the functions unwind or
|
|
354 catch handlers. The catch handler returns the address at which execution
|
|
355 should continue.
|
|
356
|
|
357 Cleanup handlers perform any cleanup necessary as the frame goes out of scope,
|
|
358 such as calling object destructors. The runtime handles the actual unwinding
|
|
359 of the stack. If an exception occurs in a cleanup handler the runtime manages
|
|
360 termination of the process. Cleanup handlers are called with the same arguments
|
|
361 as catch handlers (a pointer to the handler and a pointer to the parent stack
|
|
362 frame) and use the same mechanism described above to access frame variables
|
|
363 in the parent function. Cleanup handlers do not return a value.
|
|
364
|
|
365 The IR generated for Windows runtime based C++ exception handling is initially
|
|
366 very similar to the ``landingpad`` mechanism described above. Calls to
|
|
367 libc++abi functions (such as ``__cxa_begin_catch``/``__cxa_end_catch`` and
|
|
368 ``__cxa_throw_exception`` are replaced with calls to intrinsics or Windows
|
|
369 runtime functions (such as ``llvm.eh.begincatch``/``llvm.eh.endcatch`` and
|
|
370 ``__CxxThrowException``).
|
|
371
|
|
372 During the WinEHPrepare pass, the handler functions are outlined into handler
|
|
373 functions and the original landing pad code is replaced with a call to the
|
|
374 ``llvm.eh.actions`` intrinsic that describes the order in which handlers will
|
|
375 be processed from the logical location of the landing pad and an indirect
|
|
376 branch to the return value of the ``llvm.eh.actions`` intrinsic. The
|
|
377 ``llvm.eh.actions`` intrinsic is defined as returning the address at which
|
|
378 execution will continue. This is a temporary construct which will be removed
|
|
379 before code generation, but it allows for the accurate tracking of control
|
|
380 flow until then.
|
|
381
|
|
382 A typical landing pad will look like this after outlining:
|
|
383
|
|
384 .. code-block:: llvm
|
|
385
|
|
386 lpad:
|
|
387 %vals = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)* @__CxxFrameHandler3 to i8*)
|
|
388 cleanup
|
|
389 catch i8* bitcast (i8** @_ZTIi to i8*)
|
|
390 catch i8* bitcast (i8** @_ZTIf to i8*)
|
|
391 %recover = call i8* (...)* @llvm.eh.actions(
|
|
392 i32 3, i8* bitcast (i8** @_ZTIi to i8*), i8* (i8*, i8*)* @_Z4testb.catch.1)
|
|
393 i32 2, i8* null, void (i8*, i8*)* @_Z4testb.cleanup.1)
|
|
394 i32 1, i8* bitcast (i8** @_ZTIf to i8*), i8* (i8*, i8*)* @_Z4testb.catch.0)
|
|
395 i32 0, i8* null, void (i8*, i8*)* @_Z4testb.cleanup.0)
|
|
396 indirectbr i8* %recover, [label %try.cont1, label %try.cont2]
|
|
397
|
|
398 In this example, the landing pad represents an exception handling context with
|
|
399 two catch handlers and a cleanup handler that have been outlined. If an
|
|
400 exception is thrown with a type that matches ``_ZTIi``, the ``_Z4testb.catch.1``
|
|
401 handler will be called an no clean-up is needed. If an exception is thrown
|
|
402 with a type that matches ``_ZTIf``, first the ``_Z4testb.cleanup.1`` handler
|
|
403 will be called to perform unwind-related cleanup, then the ``_Z4testb.catch.1``
|
|
404 handler will be called. If an exception is throw which does not match either
|
|
405 of these types and the exception is handled by another frame further up the
|
|
406 call stack, first the ``_Z4testb.cleanup.1`` handler will be called, then the
|
|
407 ``_Z4testb.cleanup.0`` handler (which corresponds to a different scope) will be
|
|
408 called, and exception handling will continue at the next frame in the call
|
|
409 stack will be called. One of the catch handlers will return the address of
|
|
410 ``%try.cont1`` in the parent function and the other will return the address of
|
|
411 ``%try.cont2``, meaning that execution continues at one of those blocks after
|
|
412 an exception is caught.
|
|
413
|
|
414
|
0
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
415 Exception Handling Intrinsics
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
416 =============================
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
417
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
418 In addition to the ``landingpad`` and ``resume`` instructions, LLVM uses several
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
419 intrinsic functions (name prefixed with ``llvm.eh``) to provide exception
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
420 handling information at various points in generated code.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
421
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
422 .. _llvm.eh.typeid.for:
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
423
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
424 ``llvm.eh.typeid.for``
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
425 ----------------------
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
426
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
427 .. code-block:: llvm
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
428
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
429 i32 @llvm.eh.typeid.for(i8* %type_info)
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
430
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
431
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
432 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
|
433 function. This value can be used to compare against the result of
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
434 ``landingpad`` instruction. The single argument is a reference to a type info.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
435
|
77
|
436 Uses of this intrinsic are generated by the C++ front-end.
|
|
437
|
83
|
438 .. _llvm.eh.begincatch:
|
|
439
|
|
440 ``llvm.eh.begincatch``
|
|
441 ----------------------
|
|
442
|
|
443 .. code-block:: llvm
|
|
444
|
|
445 i8* @llvm.eh.begincatch(i8* %exn)
|
|
446
|
|
447
|
|
448 This intrinsic marks the beginning of catch handling code within the blocks
|
|
449 following a ``landingpad`` instruction. The exact behavior of this function
|
|
450 depends on the compilation target and the personality function associated
|
|
451 with the ``landingpad`` instruction.
|
|
452
|
|
453 The argument to this intrinsic is a pointer that was previously extracted from
|
|
454 the aggregate return value of the ``landingpad`` instruction. The return
|
|
455 value of the intrinsic is a pointer to the exception object to be used by the
|
|
456 catch code. This pointer is returned as an ``i8*`` value, but the actual type
|
|
457 of the object will depend on the exception that was thrown.
|
|
458
|
|
459 Uses of this intrinsic are generated by the C++ front-end. Many targets will
|
|
460 use implementation-specific functions (such as ``__cxa_begin_catch``) instead
|
|
461 of this intrinsic. The intrinsic is provided for targets that require a more
|
|
462 abstract interface.
|
|
463
|
|
464 When used in the native Windows C++ exception handling implementation, this
|
|
465 intrinsic serves as a placeholder to delimit code before a catch handler is
|
|
466 outlined. When the handler is is outlined, this intrinsic will be replaced
|
|
467 by instructions that retrieve the exception object pointer from the frame
|
|
468 allocation block.
|
|
469
|
|
470
|
|
471 .. _llvm.eh.endcatch:
|
|
472
|
|
473 ``llvm.eh.endcatch``
|
|
474 ----------------------
|
|
475
|
|
476 .. code-block:: llvm
|
|
477
|
|
478 void @llvm.eh.endcatch()
|
|
479
|
|
480
|
|
481 This intrinsic marks the end of catch handling code within the current block,
|
|
482 which will be a successor of a block which called ``llvm.eh.begincatch''.
|
|
483 The exact behavior of this function depends on the compilation target and the
|
|
484 personality function associated with the corresponding ``landingpad``
|
|
485 instruction.
|
|
486
|
|
487 There may be more than one call to ``llvm.eh.endcatch`` for any given call to
|
|
488 ``llvm.eh.begincatch`` with each ``llvm.eh.endcatch`` call corresponding to the
|
|
489 end of a different control path. All control paths following a call to
|
|
490 ``llvm.eh.begincatch`` must reach a call to ``llvm.eh.endcatch``.
|
|
491
|
|
492 Uses of this intrinsic are generated by the C++ front-end. Many targets will
|
|
493 use implementation-specific functions (such as ``__cxa_begin_catch``) instead
|
|
494 of this intrinsic. The intrinsic is provided for targets that require a more
|
|
495 abstract interface.
|
|
496
|
|
497 When used in the native Windows C++ exception handling implementation, this
|
|
498 intrinsic serves as a placeholder to delimit code before a catch handler is
|
|
499 outlined. After the handler is outlined, this intrinsic is simply removed.
|
|
500
|
|
501
|
77
|
502 SJLJ Intrinsics
|
|
503 ---------------
|
|
504
|
|
505 The ``llvm.eh.sjlj`` intrinsics are used internally within LLVM's
|
|
506 backend. Uses of them are generated by the backend's
|
|
507 ``SjLjEHPrepare`` pass.
|
|
508
|
0
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
509 .. _llvm.eh.sjlj.setjmp:
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
510
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
511 ``llvm.eh.sjlj.setjmp``
|
77
|
512 ~~~~~~~~~~~~~~~~~~~~~~~
|
0
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
513
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
514 .. code-block:: llvm
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
515
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
516 i32 @llvm.eh.sjlj.setjmp(i8* %setjmp_buf)
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
517
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
518 For SJLJ based exception handling, this intrinsic forces register saving for the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
519 current function and stores the address of the following instruction for use as
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
520 a destination address by `llvm.eh.sjlj.longjmp`_. The buffer format and the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
521 overall functioning of this intrinsic is compatible with the GCC
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
522 ``__builtin_setjmp`` implementation allowing code built with the clang and GCC
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
523 to interoperate.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
524
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
525 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
|
526 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
|
527 the target implementation of this intrinsic should place the destination address
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
528 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
|
529 available for use in a target-specific manner.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
530
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
531 .. _llvm.eh.sjlj.longjmp:
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
532
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
533 ``llvm.eh.sjlj.longjmp``
|
77
|
534 ~~~~~~~~~~~~~~~~~~~~~~~~
|
0
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
535
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
536 .. code-block:: llvm
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
537
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
538 void @llvm.eh.sjlj.longjmp(i8* %setjmp_buf)
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
539
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
540 For SJLJ based exception handling, the ``llvm.eh.sjlj.longjmp`` intrinsic is
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
541 used to implement ``__builtin_longjmp()``. The single parameter is a pointer to
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
542 a buffer populated by `llvm.eh.sjlj.setjmp`_. The frame pointer and stack
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
543 pointer are restored from the buffer, then control is transferred to the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
544 destination address.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
545
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
546 ``llvm.eh.sjlj.lsda``
|
77
|
547 ~~~~~~~~~~~~~~~~~~~~~
|
0
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
548
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
549 .. code-block:: llvm
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
550
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
551 i8* @llvm.eh.sjlj.lsda()
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
552
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
553 For SJLJ based exception handling, the ``llvm.eh.sjlj.lsda`` intrinsic returns
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
554 the address of the Language Specific Data Area (LSDA) for the current
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
555 function. The SJLJ front-end code stores this address in the exception handling
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
556 function context for use by the runtime.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
557
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
558 ``llvm.eh.sjlj.callsite``
|
77
|
559 ~~~~~~~~~~~~~~~~~~~~~~~~~
|
0
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
560
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
561 .. code-block:: llvm
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
562
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
563 void @llvm.eh.sjlj.callsite(i32 %call_site_num)
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
564
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
565 For SJLJ based exception handling, the ``llvm.eh.sjlj.callsite`` intrinsic
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
566 identifies the callsite value associated with the following ``invoke``
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
567 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
|
568 generated in matching order.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
569
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
570 Asm Table Formats
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
571 =================
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
572
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
573 There are two tables that are used by the exception handling runtime to
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
574 determine which actions should be taken when an exception is thrown.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
575
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
576 Exception Handling Frame
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
577 ------------------------
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
578
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
579 An exception handling frame ``eh_frame`` is very similar to the unwind frame
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
580 used by DWARF debug info. The frame contains all the information necessary to
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
581 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
|
582 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
|
583 exception handling frame that defines information common to all functions in the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
584 unit.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
585
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
586 Exception Tables
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
587 ----------------
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
588
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
589 An exception table contains information about what actions to take when an
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
590 exception is thrown in a particular part of a function's code. There is one
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
591 exception table per function, except leaf functions and functions that have
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
592 calls only to non-throwing functions. They do not need an exception table.
|