llvm.org GIT mirror llvm / c4f661e
Reformatting and some cleanup. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79088 91177308-0d34-0410-b5e6-96231b3b80d8 Bill Wendling 10 years ago
1 changed file(s) with 255 addition(s) and 231 deletion(s). Raw diff Collapse all Expand all
22
33
44 Exception Handling in LLVM
5
6
7 content="Exception Handling in LLVM.">
58
69
10
711
812
913
Exception Handling in LLVM
5761
5862
5963

This document is the central repository for all information pertaining to

60 exception handling in LLVM. It describes the format that LLVM exception
61 handling information takes, which is useful for those interested in creating
62 front-ends or dealing directly with the information. Further, this document
63 provides specific examples of what exception handling information is used for
64 C/C++.

64 exception handling in LLVM. It describes the format that LLVM exception
65 handling information takes, which is useful for those interested in creating
66 front-ends or dealing directly with the information. Further, this document
67 provides specific examples of what exception handling information is used for
68 in C/C++.

6569
6670
6771
7377
7478
7579

Exception handling for most programming languages is designed to recover from

76 conditions that rarely occur during general use of an application. To that end,
77 exception handling should not interfere with the main flow of an
78 application's algorithm by performing checkpointing tasks such as saving
79 the current pc or register state.

80 conditions that rarely occur during general use of an application. To that
81 end, exception handling should not interfere with the main flow of an
82 application's algorithm by performing checkpointing tasks, such as saving the
83 current pc or register state.

8084
8185

The Itanium ABI Exception Handling Specification defines a methodology for

82 providing outlying data in the form of exception tables without inlining
83 speculative exception handling code in the flow of an application's main
84 algorithm. Thus, the specification is said to add "zero-cost" to the normal
85 execution of an application.

86 providing outlying data in the form of exception tables without inlining
87 speculative exception handling code in the flow of an application's main
88 algorithm. Thus, the specification is said to add "zero-cost" to the normal
89 execution of an application.

8690
8791

A more complete description of the Itanium ABI exception handling runtime

88 support of can be found at
89 href="http://www.codesourcery.com/cxx-abi/abi-eh.html">Itanium C++ ABI:
90 Exception Handling. A description of the exception frame format can be found
91 at 92 Core-generic/ehframechpt.html">Exception Frames, with details of the Dwarf
93 specification at Dwarf 3
94 Standard. A description for the C++ exception table formats can be found at
95 Exception Handling
96 Tables.

92 support of can be found at
93 Itanium C++ ABI:
94 Exception Handling. A description of the exception frame format can be
95 found at
96 Exception
97 Frames, with details of the DWARF 3 specification at
98 DWARF 3 Standard.
99 A description for the C++ exception table formats can be found at
100 Exception Handling
101 Tables.

97102
98103
99104
104109
105110
106111
107

When an exception is thrown in llvm code, the runtime does a best effort to

108 find a handler suited to process the circumstance.

112

When an exception is thrown in LLVM code, the runtime does its best to find a

113 handler suited to processing the circumstance.

109114
110115

The runtime first attempts to find an exception frame corresponding to

111 the function where the exception was thrown. If the programming language (ex.
112 C++) supports exception handling, the exception frame contains a reference to an
113 exception table describing how to process the exception. If the language (ex.
114 C) does not support exception handling or if the exception needs to be forwarded
115 to a prior activation, the exception frame contains information about how to
116 unwind the current activation and restore the state of the prior activation.
117 This process is repeated until the exception is handled. If the exception is
118 not handled and no activations remain, then the application is terminated with
119 an appropriate error message.

120
121

Since different programming languages have different behaviors when handling

122 exceptions, the exception handling ABI provides a mechanism for supplying
123 personalities. An exception handling personality is defined by way of a
124 personality function (ex. for C++ __gxx_personality_v0) which
125 receives the context of the exception, an exception structure containing
126 the exception object type and value, and a reference to the exception table for
127 the current function. The personality function for the current compile unit is
128 specified in a common exception frame.

116 the function where the exception was thrown. If the programming language
117 (e.g. C++) supports exception handling, the exception frame contains a
118 reference to an exception table describing how to process the exception. If
119 the language (e.g. C) does not support exception handling, or if the
120 exception needs to be forwarded to a prior activation, the exception frame
121 contains information about how to unwind the current activation and restore
122 the state of the prior activation. This process is repeated until the
123 exception is handled. If the exception is not handled and no activations
124 remain, then the application is terminated with an appropriate error
125 message.

126
127

Because different programming languages have different behaviors when

128 handling exceptions, the exception handling ABI provides a mechanism for
129 supplying personalities. An exception handling personality is defined
130 by way of a personality function (e.g. __gxx_personality_v0
131 in C++), which receives the context of the exception, an exception
132 structure containing the exception object type and value, and a reference
133 to the exception table for the current function. The personality function
134 for the current compile unit is specified in a common exception
135 frame.

129136
130137

The organization of an exception table is language dependent. For C++, an

131 exception table is organized as a series of code ranges defining what to do if
132 an exception occurs in that range. Typically, the information associated with a
133 range defines which types of exception objects (using C++ type info) that
134 are handled in that range, and an associated action that should take place.
135 Actions typically pass control to a landing pad.

136
137

A landing pad corresponds to the code found in the catch portion of a

138 try/catch sequence. When execution resumes at a landing pad, it receives the
139 exception structure and a selector corresponding to the type of exception
140 thrown. The selector is then used to determine which catch should actually
141 process the exception.

138 exception table is organized as a series of code ranges defining what to do
139 if an exception occurs in that range. Typically, the information associated
140 with a range defines which types of exception objects (using C++ type
141 info) that are handled in that range, and an associated action that
142 should take place. Actions typically pass control to a landing
143 pad.

144
145

A landing pad corresponds to the code found in the catch portion of

146 a try/catch sequence. When execution resumes at a landing
147 pad, it receives the exception structure and a selector corresponding to
148 the type of exception thrown. The selector is then used to determine
149 which catch should actually process the exception.

142150
143151
144152
150158
151159
152160

At the time of this writing, only C++ exception handling support is available

153 in LLVM. So the remainder of this document will be somewhat C++-centric.

161 in LLVM. So the remainder of this document will be somewhat C++-centric.

154162
155163

From the C++ developers perspective, exceptions are defined in terms of the

156 throw and try/catch statements. In this section we will
157 describe the implementation of llvm exception handling in terms of C++
158 examples.

164 throw and try/catch statements. In this section
165 we will describe the implementation of LLVM exception handling in terms of
166 C++ examples.

159167
160168
161169
167175
168176
169177

Languages that support exception handling typically provide a throw

170 operation to initiate the exception process. Internally, a throw operation
171 breaks down into two steps. First, a request is made to allocate exception
172 space for an exception structure. This structure needs to survive beyond the
173 current activation. This structure will contain the type and value of the
174 object being thrown. Second, a call is made to the runtime to raise the
175 exception, passing the exception structure as an argument.

176
177

In C++, the allocation of the exception structure is done by the

178 __cxa_allocate_exception runtime function. The exception raising is
179 handled by __cxa_throw. The type of the exception is represented using
180 a C++ RTTI type info structure.

178 operation to initiate the exception process. Internally, a throw operation
179 breaks down into two steps. First, a request is made to allocate exception
180 space for an exception structure. This structure needs to survive beyond the
181 current activation. This structure will contain the type and value of the
182 object being thrown. Second, a call is made to the runtime to raise the
183 exception, passing the exception structure as an argument.

184
185

In C++, the allocation of the exception structure is done by

186 the __cxa_allocate_exception runtime function. The exception
187 raising is handled by __cxa_throw. The type of the exception is
188 represented using a C++ RTTI structure.

181189
182190
183191
188196
189197
190198
191

A call within the scope of a try statement can potentially raise an exception.

192 In those circumstances, the LLVM C++ front-end replaces the call with an
193 invoke instruction. Unlike a call, the invoke has two potential
194 continuation points; where to continue when the call succeeds as per normal, and
195 where to continue if the call raises an exception, either by a throw or the
196 unwinding of a throw.

197
198

The term used to define a the place where an invoke continues after an

199 exception is called a landing pad. LLVM landing pads are conceptually
200 alternative function entry points where a exception structure reference and a type
201 info index are passed in as arguments. The landing pad saves the exception
202 structure reference and then proceeds to select the catch block that corresponds
203 to the type info of the exception object.

204
205

Two llvm intrinsic functions are used convey information about the landing

206 pad to the back end.

207
208

llvm.eh.exception takes no

209 arguments and returns a pointer to the exception structure. This only returns a
210 sensible value if called after an invoke has branched to a landing pad. Due to
211 codegen limitations, it must currently be called in the landing pad itself.

212
213

llvm.eh.selector takes a minimum of

214 three arguments. The first argument is the reference to the exception
215 structure. The second argument is a reference to the personality function to be
216 used for this try catch sequence. Each of the remaining arguments is either a
217 reference to the type info for a catch statement,
218 a filter expression,
219 or the number zero representing a cleanup.
220 The exception is tested against the arguments sequentially from first to last.
221 The result of the llvm.eh.selector is a
222 positive number if the exception matched a type info, a negative number if it matched
223 a filter, and zero if it matched a cleanup. If nothing is matched, the behaviour of
224 the program is undefined.
225 This only returns a sensible value if called after an invoke has branched to a
226 landing pad. Due to codegen limitations, it must currently be called in the
227 landing pad itself.
228 If a type info matched then the selector value is the index of the type info in
229 the exception table, which can be obtained using the
230 <a href="#llvm_eh_typeid_for">llvm.eh.typeid.for intrinsic.

199 <p>A call within the scope of a try statement can potentially raise an
200 exception. In those circumstances, the LLVM C++ front-end replaces the call
201 with an invoke instruction. Unlike a call, the invoke has
202 two potential continuation points: where to continue when the call succeeds
203 as per normal; and where to continue if the call raises an exception, either
204 by a throw or the unwinding of a throw.

205
206

The term used to define a the place where an invoke continues after

207 an exception is called a landing pad. LLVM landing pads are
208 conceptually alternative function entry points where an exception structure
209 reference and a type info index are passed in as arguments. The landing pad
210 saves the exception structure reference and then proceeds to select the catch
211 block that corresponds to the type info of the exception object.

212
213

Two LLVM intrinsic functions are used to convey information about the landing

214 pad to the back end.

215
216
217
  • llvm.eh.exception takes no
  • 218 arguments and returns a pointer to the exception structure. This only
    219 returns a sensible value if called after an invoke has branched
    220 to a landing pad. Due to code generation limitations, it must currently
    221 be called in the landing pad itself.
    222
    223
  • llvm.eh.selector takes a minimum
  • 224 of three arguments. The first argument is the reference to the exception
    225 structure. The second argument is a reference to the personality function
    226 to be used for this try/catch sequence. Each of the
    227 remaining arguments is either a reference to the type info for
    228 a catch statement, a filter
    229 expression, or the number zero (0) representing
    230 a cleanup. The exception is tested against the
    231 arguments sequentially from first to last. The result of
    232 the llvm.eh.selector is a
    233 positive number if the exception matched a type info, a negative number if
    234 it matched a filter, and zero if it matched a cleanup. If nothing is
    235 matched, the behaviour of the program
    236 is undefined. This only returns a sensible
    237 value if called after an invoke has branched to a landing pad.
    238 Due to codegen limitations, it must currently be called in the landing pad
    239 itself. If a type info matched, then the selector value is the index of
    240 the type info in the exception table, which can be obtained using the
    241 llvm.eh.typeid.for
    242 intrinsic.
    243
    231244
    232245

    Once the landing pad has the type info selector, the code branches to the

    233 code for the first catch. The catch then checks the value of the type info
    234 selector against the index of type info for that catch. Since the type info
    235 index is not known until all the type info have been gathered in the backend,
    236 the catch code will call the
    237 href="#llvm_eh_typeid_for">llvm.eh.typeid.for intrinsic to
    238 determine the index for a given type info. If the catch fails to match the
    239 selector then control is passed on to the next catch. Note: Since the landing
    240 pad will not be used if there is no match in the list of type info on the call
    241 to llvm.eh.selector, then neither the
    242 last catch nor catch all need to perform the the check against the
    243 selector.

    244
    245

    Finally, the entry and exit of catch code is bracketed with calls to

    246 __cxa_begin_catch and __cxa_end_catch.
    247 __cxa_begin_catch takes a exception structure reference as an argument
    248 and returns the value of the exception object. __cxa_end_catch
    249 takes a exception structure reference as an argument. This function clears the
    250 exception from the exception space. Note: a rethrow from within the catch may
    251 replace this call with a __cxa_rethrow.

    246 code for the first catch. The catch then checks the value of the type info
    247 selector against the index of type info for that catch. Since the type info
    248 index is not known until all the type info have been gathered in the backend,
    249 the catch code will call the
    250 llvm.eh.typeid.for intrinsic
    251 to determine the index for a given type info. If the catch fails to match
    252 the selector then control is passed on to the next catch. Note: Since the
    253 landing pad will not be used if there is no match in the list of type info on
    254 the call to llvm.eh.selector, then
    255 neither the last catch nor catch all need to perform the check
    256 against the selector.

    257
    258

    Finally, the entry and exit of catch code is bracketed with calls

    259 to __cxa_begin_catch and __cxa_end_catch.

    260
    261
    262
  • __cxa_begin_catch takes a exception structure reference as an
  • 263 argument and returns the value of the exception object.
    264
    265
  • __cxa_end_catch takes a exception structure reference as an
  • 266 argument. This function clears the exception from the exception space.
    267 Note: a rethrow from within the catch may replace this call with
    268 a __cxa_rethrow.
    269
    252270
    253271
    254272
    259277
    260278
    261279
    262

    To handle destructors and cleanups in try code, control may not run directly

    263 from a landing pad to the first catch. Control may actually flow from the
    264 landing pad to clean up code and then to the first catch. Since the required
    265 clean up for each invoke in a try may be different (ex., intervening
    266 constructor), there may be several landing pads for a given try. If cleanups
    267 need to be run, the number zero should be passed as the last
    268 llvm.eh.selector argument.
    269 However for C++ a null i8* must be passed
    270 instead.
    271 </p>
    280 <p>To handle destructors and cleanups in try code, control may not run
    281 directly from a landing pad to the first catch. Control may actually flow
    282 from the landing pad to clean up code and then to the first catch. Since the
    283 required clean up for each invoke in a try may be different
    284 (e.g. intervening constructor), there may be several landing pads for a given
    285 try. If cleanups need to be run, the number zero should be passed as the
    286 last llvm.eh.selector argument.
    287 However for C++ a null i8* must
    288 be passed instead.

    272289
    273290
    274291
    279296
    280297
    281298
    282

    C++ allows the specification of which exception types can be thrown from

    283 a function. To represent this a top level landing pad may exist to filter out
    284 invalid types. To express this in LLVM code the landing pad will call
    285 href="#llvm_eh_selector">llvm.eh.selector. The arguments are a
    286 reference to the exception structure, a reference to the personality function,
    287 the length of the filter expression (the number of type infos plus one),
    288 followed by the type infos themselves.
    289 llvm.eh.selector will return a negative
    290 value if the exception does not match any of the type infos. If no match is
    291 found then a call to __cxa_call_unexpected should be made, otherwise
    292 _Unwind_Resume. Each of these functions requires a reference to the
    293 exception structure. Note that the most general form of an
    294 llvm.eh.selector call can contain
    295 any number of type infos, filter expressions and cleanups (though having more
    296 than one cleanup is pointless). The LLVM C++ front-end can generate such
    297 llvm.eh.selector calls due to inlining
    298 creating nested exception handling scopes.

    299

    C++ allows the specification of which exception types can be thrown from a

    300 function. To represent this a top level landing pad may exist to filter out
    301 invalid types. To express this in LLVM code the landing pad will
    302 call llvm.eh.selector. The
    303 arguments are a reference to the exception structure, a reference to the
    304 personality function, the length of the filter expression (the number of type
    305 infos plus one), followed by the type infos themselves.
    306 llvm.eh.selector will return a
    307 negative value if the exception does not match any of the type infos. If no
    308 match is found then a call to __cxa_call_unexpected should be made,
    309 otherwise _Unwind_Resume. Each of these functions requires a
    310 reference to the exception structure. Note that the most general form of an
    311 llvm.eh.selector call can contain
    312 any number of type infos, filter expressions and cleanups (though having more
    313 than one cleanup is pointless). The LLVM C++ front-end can generate such
    314 llvm.eh.selector calls due to
    315 inlining creating nested exception handling scopes.

    299316
    300317
    301318
    307324
    308325
    309326

    The semantics of the invoke instruction require that any exception that

    310 unwinds through an invoke call should result in a branch to the invoke's unwind
    311 label. However such a branch will only happen if the
    312 llvm.eh.selector matches.
    313 Thus in order to ensure correct operation, the front-end must only generate
    314 llvm.eh.selector calls that are
    315 guaranteed to always match whatever exception unwinds through the invoke.
    316 For most languages it is enough to pass zero, indicating the presence of
    317 a cleanup, as the last
    318 llvm.eh.selector argument.
    319 However for C++ this is not sufficient, because the C++ personality function
    320 will terminate the program if it detects that unwinding the exception only
    321 results in matches with cleanups. For C++ a null i8* should
    322 be passed as the last
    323 llvm.eh.selector argument instead.
    324 This is interpreted as a catch-all by the C++ personality function, and will
    325 always match.
    326

    327 unwinds through an invoke call should result in a branch to the invoke's
    328 unwind label. However such a branch will only happen if the
    329 llvm.eh.selector matches. Thus in
    330 order to ensure correct operation, the front-end must only generate
    331 llvm.eh.selector calls that are
    332 guaranteed to always match whatever exception unwinds through the invoke.
    333 For most languages it is enough to pass zero, indicating the presence of
    334 a cleanup, as the
    335 last llvm.eh.selector argument.
    336 However for C++ this is not sufficient, because the C++ personality function
    337 will terminate the program if it detects that unwinding the exception only
    338 results in matches with cleanups. For C++ a null i8* should be
    339 passed as the last llvm.eh.selector
    340 argument instead. This is interpreted as a catch-all by the C++ personality
    341 function, and will always match.

    327342
    328343
    329344
    335350
    336351
    337352

    LLVM uses several intrinsic functions (name prefixed with "llvm.eh") to

    338 provide exception handling information at various points in generated code.

    353 provide exception handling information at various points in generated
    354 code.

    339355
    340356
    341357
    346362
    347363
    348364
    
                      
                    
    349 i8* %llvm.eh.exception( )
    365 i8* %llvm.eh.exception( )
    350366
    367
    351368
    352369

    This intrinsic returns a pointer to the exception structure.

    353370
    360377
    361378
    362379
    
                      
                    
    363 i32 %llvm.eh.selector.i32(i8*, i8*, i8*, ...)
    364 i64 %llvm.eh.selector.i64(i8*, i8*, i8*, ...)
    380 i32 %llvm.eh.selector.i32(i8*, i8*, i8*, ...)
    381 i64 %llvm.eh.selector.i64(i8*, i8*, i8*, ...)
    365382
    383
    366384
    367385

    This intrinsic is used to compare the exception with the given type infos,

    368 filters and cleanups.

    386 filters and cleanups.

    369387
    370388

    llvm.eh.selector takes a minimum of

    371 three arguments. The first argument is the reference to the exception
    372 structure. The second argument is a reference to the personality function to be
    373 used for this try catch sequence. Each of the remaining arguments is either a
    374 reference to the type info for a catch statement,
    375 a filter expression,
    376 or the number zero representing a cleanup.
    377 The exception is tested against the arguments sequentially from first to last.
    378 The result of the llvm.eh.selector is a
    379 positive number if the exception matched a type info, a negative number if it matched
    380 a filter, and zero if it matched a cleanup. If nothing is matched, the behaviour of
    381 the program is undefined.
    382 If a type info matched then the selector value is the index of the type info in
    383 the exception table, which can be obtained using the
    384 llvm.eh.typeid.for intrinsic.

    389 three arguments. The first argument is the reference to the exception
    390 structure. The second argument is a reference to the personality function to
    391 be used for this try catch sequence. Each of the remaining arguments is
    392 either a reference to the type info for a catch statement,
    393 a filter expression, or the number zero
    394 representing a cleanup. The exception is tested
    395 against the arguments sequentially from first to last. The result of
    396 the llvm.eh.selector is a positive
    397 number if the exception matched a type info, a negative number if it matched
    398 a filter, and zero if it matched a cleanup. If nothing is matched, the
    399 behaviour of the program is undefined. If a type
    400 info matched then the selector value is the index of the type info in the
    401 exception table, which can be obtained using the
    402 llvm.eh.typeid.for intrinsic.

    385403
    386404
    387405
    392410
    393411
    394412
    
                      
                    
    395 i32 %llvm.eh.typeid.for.i32(i8*)
    396 i64 %llvm.eh.typeid.for.i64(i8*)
    413 i32 %llvm.eh.typeid.for.i32(i8*)
    414 i64 %llvm.eh.typeid.for.i64(i8*)
    397415
    416
    398417
    399418

    This intrinsic returns the type info index in the exception table of the

    400 current function. This value can be used to compare against the result of
    401 href="#llvm_eh_selector">llvm.eh.selector. The single argument is
    402 a reference to a type info.

    419 current function. This value can be used to compare against the result
    420 of llvm.eh.selector. The single
    421 argument is a reference to a type info.

    403422
    404423
    405424
    410429
    411430
    412431
    
                      
                    
    413 i32 %llvm.eh.sjlj.setjmp(i8*)
    432 i32 %llvm.eh.sjlj.setjmp(i8*)
    414433
    415
    416

    The SJLJ exception handling uses this intrinsic to force register saving

    417 for the current function and to store the address of the following instruction
    418 for use as a destination address by
    419 llvm.eh.sjlj.longjmp. The buffer format and the overall functioning
    420 of this intrinsic is compatible with the GCC __builtin_setjmp
    421 implementation, allowing code built with the two compilers to interoperate.

    422
    423

    The single parameter is a pointer to a five word buffer in which the

    424 calling context is saved. The front end places the frame pointer in the
    425 first word, and the target implementation of this intrinsic should place the
    426 destination address for a
    427 llvm.eh.sjlj.longjmp in the second word. The following three words
    428 are available for use in a target-specific manner.>
    434 >
    435
    436

    The SJLJ exception handling uses this intrinsic to force register saving for

    437 the current function and to store the address of the following instruction
    438 for use as a destination address by
    439 llvm.eh.sjlj.longjmp. The buffer format and the overall
    440 functioning of this intrinsic is compatible with the GCC
    441 __builtin_setjmp implementation, allowing code built with the
    442 two compilers to interoperate.

    443
    444

    The single parameter is a pointer to a five word buffer in which the calling

    445 context is saved. The front end places the frame pointer in the first word,
    446 and the target implementation of this intrinsic should place the destination
    447 address for a
    448 llvm.eh.sjlj.longjmp in the
    449 second word. The following three words are available for use in a
    450 target-specific manner.

    429451
    430452
    431453
    436458
    437459
    438460
    
                      
                    
    439 i8* %llvm.eh.sjlj.lsda( )
    461 i8* %llvm.eh.sjlj.lsda( )
    440462
    463
    441464
    442465

    Used for SJLJ based exception handling, the

    443 llvm.eh.sjlj.lsda intrinsic returns the address of the Language
    444 Specific Data Area (LSDA) for the current function. The SJLJ front-end code
    445 stores this address in the exception handling function context for use by
    446 the runtime.

    466 llvm.eh.sjlj.lsda intrinsic returns the address of the Language
    467 Specific Data Area (LSDA) for the current function. The SJLJ front-end code
    468 stores this address in the exception handling function context for use by the
    469 runtime.

    447470
    448471
    449472
    454477
    455478
    456479
    
                      
                    
    457 void %llvm.eh.sjlj.callsite(i32)
    480 void %llvm.eh.sjlj.callsite(i32)
    458481
    459
    460

    The SJLJ front-end allocates call site indices for invoke instrucitons.

    461 These values are passed to the back-end via the
    462 llvm.eh.sjlj.callsite
    463 intrinsic, where they are used to build the LSDA call-site table.>
    482 >
    483
    484

    The SJLJ front-end allocates call site indices for invoke instrucitons.

    485 These values are passed to the back-end via the
    486 llvm.eh.sjlj.callsite
    487 intrinsic, where they are used to build the LSDA call-site table.

    464488
    465489
    466490
    472496
    473497
    474498

    There are two tables that are used by the exception handling runtime to

    475 determine which actions should take place when an exception is thrown.

    499 determine which actions should take place when an exception is thrown.

    476500
    477501
    478502
    484508
    485509
    486510

    An exception handling frame eh_frame is very similar to the unwind

    487 frame used by dwarf debug info. The frame contains all the information
    488 necessary to tear down the current frame and restore the state of the prior
    489 frame. There is an exception handling frame for each function in a compile
    490 unit, plus a common exception handling frame that defines information common to
    491 all functions in the unit.

    511 frame used by dwarf debug info. The frame contains all the information
    512 necessary to tear down the current frame and restore the state of the prior
    513 frame. There is an exception handling frame for each function in a compile
    514 unit, plus a common exception handling frame that defines information common
    515 to all functions in the unit.

    492516
    493517

    Todo - Table details here.

    494518
    502526
    503527
    504528

    An exception table contains information about what actions to take when an

    505 exception is thrown in a particular part of a function's code. There is
    506 one exception table per function except leaf routines and functions that have
    507 only calls to non-throwing functions will not need an exception table.

    529 exception is thrown in a particular part of a function's code. There is one
    530 exception table per function except leaf routines and functions that have
    531 only calls to non-throwing functions will not need an exception table.

    508532
    509533

    Todo - Table details here.

    510534
    519543
    520544
    521545
    522
  • Testing/Testing/Testing.

  • 546
  • Testing/Testing/Testing.
  • 523547
    524548
    525549