docs/ExceptionHandling.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   2                       "http://www.w3.org/TR/html4/strict.dtd">
   3 <html>
   4 <head>
   5   <title>Exception Handling in LLVM</title>
   6   <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
   7   <meta name="description"
   8         content="Exception Handling in LLVM.">
   9   <link rel="stylesheet" href="llvm.css" type="text/css">
  10 </head>
  11
  12 <body>
  13
  14 <h1>Exception Handling in LLVM</h1>
  15
  16 <table class="layout" style="width:100%">
  17   <tr class="layout">
  18     <td class="left">
  19 <ul>
  20   <li><a href="#introduction">Introduction</a>
  21   <ol>
  22     <li><a href="#itanium">Itanium ABI Zero-cost Exception Handling</a></li>
  23     <li><a href="#sjlj">Setjmp/Longjmp Exception Handling</a></li>
  24     <li><a href="#overview">Overview</a></li>
  25   </ol></li>
  26   <li><a href="#codegen">LLVM Code Generation</a>
  27   <ol>
  28     <li><a href="#throw">Throw</a></li>
  29     <li><a href="#try_catch">Try/Catch</a></li>
  30     <li><a href="#cleanups">Cleanups</a></li>
  31     <li><a href="#throw_filters">Throw Filters</a></li>
  32     <li><a href="#restrictions">Restrictions</a></li>
  33   </ol></li>
  34   <li><a href="#format_common_intrinsics">Exception Handling Intrinsics</a>
  35   <ol>
  36         <li><a href="#llvm_eh_typeid_for"><tt>llvm.eh.typeid.for</tt></a></li>
  37         <li><a href="#llvm_eh_sjlj_setjmp"><tt>llvm.eh.sjlj.setjmp</tt></a></li>
  38         <li><a href="#llvm_eh_sjlj_longjmp"><tt>llvm.eh.sjlj.longjmp</tt></a></li>
  39         <li><a href="#llvm_eh_sjlj_lsda"><tt>llvm.eh.sjlj.lsda</tt></a></li>
  40         <li><a href="#llvm_eh_sjlj_callsite"><tt>llvm.eh.sjlj.callsite</tt></a></li>
  41         <li><a href="#llvm_eh_sjlj_dispatchsetup"><tt>llvm.eh.sjlj.dispatchsetup</tt></a></li>
  42   </ol></li>
  43   <li><a href="#asm">Asm Table Formats</a>
  44   <ol>
  45     <li><a href="#unwind_tables">Exception Handling Frame</a></li>
  46     <li><a href="#exception_tables">Exception Tables</a></li>
  47   </ol></li>
  48   <li><a href="#todo">ToDo</a></li>
  49 </ul>
  50 </td>
  51 </tr></table>
  52
  53 <div class="doc_author">
  54   <p>Written by <a href="mailto:jlaskey@mac.com">Jim Laskey</a></p>
  55 </div>
  56
  57
  58 <!-- *********************************************************************** -->
  59 <h2><a name="introduction">Introduction</a></h2>
  60 <!-- *********************************************************************** -->
  61
  62 <div>
  63
  64 <p>This document is the central repository for all information pertaining to
  65    exception handling in LLVM.  It describes the format that LLVM exception
  66    handling information takes, which is useful for those interested in creating
  67    front-ends or dealing directly with the information.  Further, this document
  68    provides specific examples of what exception handling information is used for
  69    in C and C++.</p>
  70
  71 <!-- ======================================================================= -->
  72 <h3>
  73   <a name="itanium">Itanium ABI Zero-cost Exception Handling</a>
  74 </h3>
  75
  76 <div>
  77
  78 <p>Exception handling for most programming languages is designed to recover from
  79    conditions that rarely occur during general use of an application.  To that
  80    end, exception handling should not interfere with the main flow of an
  81    application's algorithm by performing checkpointing tasks, such as saving the
  82    current pc or register state.</p>
  83
  84 <p>The Itanium ABI Exception Handling Specification defines a methodology for
  85    providing outlying data in the form of exception tables without inlining
  86    speculative exception handling code in the flow of an application's main
  87    algorithm.  Thus, the specification is said to add "zero-cost" to the normal
  88    execution of an application.</p>
  89
  90 <p>A more complete description of the Itanium ABI exception handling runtime
  91    support of can be found at
  92    <a href="http://www.codesourcery.com/cxx-abi/abi-eh.html">Itanium C++ ABI:
  93    Exception Handling</a>. A description of the exception frame format can be
  94    found at
  95    <a href="http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html">Exception
  96    Frames</a>, with details of the DWARF 4 specification at
  97    <a href="http://dwarfstd.org/Dwarf4Std.php">DWARF 4 Standard</a>.
  98    A description for the C++ exception table formats can be found at
  99    <a href="http://www.codesourcery.com/cxx-abi/exceptions.pdf">Exception Handling
 100    Tables</a>.</p>
 101
 102 </div>
 103
 104 <!-- ======================================================================= -->
 105 <h3>
 106   <a name="sjlj">Setjmp/Longjmp Exception Handling</a>
 107 </h3>
 108
 109 <div>
 110
 111 <p>Setjmp/Longjmp (SJLJ) based exception handling uses LLVM intrinsics
 112    <a href="#llvm_eh_sjlj_setjmp"><tt>llvm.eh.sjlj.setjmp</tt></a> and
 113    <a href="#llvm_eh_sjlj_longjmp"><tt>llvm.eh.sjlj.longjmp</tt></a> to
 114    handle control flow for exception handling.</p>
 115
 116 <p>For each function which does exception processing &mdash; be
 117    it <tt>try</tt>/<tt>catch</tt> blocks or cleanups &mdash; that function
 118    registers itself on a global frame list. When exceptions are unwinding, the
 119    runtime uses this list to identify which functions need processing.<p>
 120
 121 <p>Landing pad selection is encoded in the call site entry of the function
 122    context. The runtime returns to the function via
 123    <a href="#llvm_eh_sjlj_longjmp"><tt>llvm.eh.sjlj.longjmp</tt></a>, where
 124    a switch table transfers control to the appropriate landing pad based on
 125    the index stored in the function context.</p>
 126
 127 <p>In contrast to DWARF exception handling, which encodes exception regions
 128    and frame information in out-of-line tables, SJLJ exception handling
 129    builds and removes the unwind frame context at runtime. This results in
 130    faster exception handling at the expense of slower execution when no
 131    exceptions are thrown. As exceptions are, by their nature, intended for
 132    uncommon code paths, DWARF exception handling is generally preferred to
 133    SJLJ.</p>
 134
 135 </div>
 136
 137 <!-- ======================================================================= -->
 138 <h3>
 139   <a name="overview">Overview</a>
 140 </h3>
 141
 142 <div>
 143
 144 <p>When an exception is thrown in LLVM code, the runtime does its best to find a
 145    handler suited to processing the circumstance.</p>
 146
 147 <p>The runtime first attempts to find an <i>exception frame</i> corresponding to
 148    the function where the exception was thrown.  If the programming language
 149    supports exception handling (e.g. C++), the exception frame contains a
 150    reference to an exception table describing how to process the exception.  If
 151    the language does not support exception handling (e.g. C), or if the
 152    exception needs to be forwarded to a prior activation, the exception frame
 153    contains information about how to unwind the current activation and restore
 154    the state of the prior activation.  This process is repeated until the
 155    exception is handled. If the exception is not handled and no activations
 156    remain, then the application is terminated with an appropriate error
 157    message.</p>
 158
 159 <p>Because different programming languages have different behaviors when
 160    handling exceptions, the exception handling ABI provides a mechanism for
 161    supplying <i>personalities</i>. An exception handling personality is defined
 162    by way of a <i>personality function</i> (e.g. <tt>__gxx_personality_v0</tt>
 163    in C++), which receives the context of the exception, an <i>exception
 164    structure</i> containing the exception object type and value, and a reference
 165    to the exception table for the current function.  The personality function
 166    for the current compile unit is specified in a <i>common exception
 167    frame</i>.</p>
 168
 169 <p>The organization of an exception table is language dependent. For C++, an
 170    exception table is organized as a series of code ranges defining what to do
 171    if an exception occurs in that range. Typically, the information associated
 172    with a range defines which types of exception objects (using C++ <i>type
 173    info</i>) that are handled in that range, and an associated action that
 174    should take place. Actions typically pass control to a <i>landing
 175    pad</i>.</p>
 176
 177 <p>A landing pad corresponds roughly to the code found in the <tt>catch</tt>
 178    portion of a <tt>try</tt>/<tt>catch</tt> sequence. When execution resumes at
 179    a landing pad, it receives an <i>exception structure</i> and a
 180    <i>selector value</i> corresponding to the <i>type</i> of exception
 181    thrown. The selector is then used to determine which <i>catch</i> should
 182    actually process the exception.</p>
 183
 184 </div>
 185
 186 </div>
 187
 188 <!-- ======================================================================= -->
 189 <h2>
 190   <a name="codegen">LLVM Code Generation</a>
 191 </h2>
 192
 193 <div>
 194
 195 <p>From a C++ developer's perspective, exceptions are defined in terms of the
 196    <tt>throw</tt> and <tt>try</tt>/<tt>catch</tt> statements. In this section
 197    we will describe the implementation of LLVM exception handling in terms of
 198    C++ examples.</p>
 199
 200 <!-- ======================================================================= -->
 201 <h3>
 202   <a name="throw">Throw</a>
 203 </h3>
 204
 205 <div>
 206
 207 <p>Languages that support exception handling typically provide a <tt>throw</tt>
 208    operation to initiate the exception process. Internally, a <tt>throw</tt>
 209    operation breaks down into two steps.</p>
 210
 211 <ol>
 212   <li>A request is made to allocate exception space for an exception structure.
 213       This structure needs to survive beyond the current activation. This
 214       structure will contain the type and value of the object being thrown.</li>
 215
 216   <li>A call is made to the runtime to raise the exception, passing the
 217       exception structure as an argument.</li>
 218 </ol>
 219
 220 <p>In C++, the allocation of the exception structure is done by the
 221    <tt>__cxa_allocate_exception</tt> runtime function. The exception raising is
 222    handled by <tt>__cxa_throw</tt>. The type of the exception is represented
 223    using a C++ RTTI structure.</p>
 224
 225 </div>
 226
 227 <!-- ======================================================================= -->
 228 <h3>
 229   <a name="try_catch">Try/Catch</a>
 230 </h3>
 231
 232 <div>
 233
 234 <p>A call within the scope of a <i>try</i> statement can potentially raise an
 235    exception. In those circumstances, the LLVM C++ front-end replaces the call
 236    with an <tt>invoke</tt> instruction. Unlike a call, the <tt>invoke</tt> has
 237    two potential continuation points:</p>
 238
 239 <ol>
 240   <li>where to continue when the call succeeds as per normal, and</li>
 241
 242   <li>where to continue if the call raises an exception, either by a throw or
 243       the unwinding of a throw</li>
 244 </ol>
 245
 246 <p>The term used to define a the place where an <tt>invoke</tt> continues after
 247    an exception is called a <i>landing pad</i>. LLVM landing pads are
 248    conceptually alternative function entry points where an exception structure
 249    reference and a type info index are passed in as arguments. The landing pad
 250    saves the exception structure reference and then proceeds to select the catch
 251    block that corresponds to the type info of the exception object.</p>
 252
 253 <p>The LLVM <a href="LangRef.html#i_landingpad"><tt>landingpad</tt>
 254    instruction</a> is used to convey information about the landing pad to the
 255    back end. For C++, the <tt>landingpad</tt> instruction returns a pointer and
 256    integer pair corresponding to the pointer to the <i>exception structure</i>
 257    and the <i>selector value</i> respectively.</p>
 258
 259 <p>The <tt>landingpad</tt> instruction takes a reference to the personality
 260    function to be used for this <tt>try</tt>/<tt>catch</tt> sequence. The
 261    remainder of the instruction is a list of <i>cleanup</i>, <i>catch</i>,
 262    and <i>filter</i> clauses. The exception is tested against the clauses
 263    sequentially from first to last. The selector value is a positive number if
 264    the exception matched a type info, a negative number if it matched a filter,
 265    and zero if it matched a cleanup. If nothing is matched, the behavior of the
 266    program is <a href="#restrictions">undefined</a>. If a type info matched,
 267    then the selector value is the index of the type info in the exception table,
 268    which can be obtained using the
 269    <a href="#llvm_eh_typeid_for"><tt>llvm.eh.typeid.for</tt></a> intrinsic.</p>
 270
 271 <p>Once the landing pad has the type info selector, the code branches to the
 272    code for the first catch. The catch then checks the value of the type info
 273    selector against the index of type info for that catch.  Since the type info
 274    index is not known until all the type infos have been gathered in the
 275    backend, the catch code must call the
 276    <a href="#llvm_eh_typeid_for"><tt>llvm.eh.typeid.for</tt></a> intrinsic to
 277    determine the index for a given type info. If the catch fails to match the
 278    selector then control is passed on to the next catch.</p>
 279
 280 <p><b>Note:</b> Since the landing pad will not be used if there is no match in
 281    the list of type info on the call to the <tt>landingpad</tt> instruction,
 282    then neither the last catch nor <i>catch all</i> need to perform the check
 283    against the selector.</p>
 284
 285 <p>Finally, the entry and exit of catch code is bracketed with calls to
 286    <tt>__cxa_begin_catch</tt> and <tt>__cxa_end_catch</tt>.</p>
 287
 288 <ul>
 289   <li><tt>__cxa_begin_catch</tt> takes an exception structure reference as an
 290       argument and returns the value of the exception object.</li>
 291
 292   <li><tt>__cxa_end_catch</tt> takes no arguments. This function:<br><br>
 293     <ol>
 294       <li>Locates the most recently caught exception and decrements its handler
 295           count,</li>
 296       <li>Removes the exception from the <i>caught</i> stack if the handler
 297           count goes to zero, and</li>
 298       <li>Destroys the exception if the handler count goes to zero and the
 299           exception was not re-thrown by throw.</li>
 300     </ol>
 301     <p><b>Note:</b> a rethrow from within the catch may replace this call with
 302        a <tt>__cxa_rethrow</tt>.</p></li>
 303 </ul>
 304
 305 </div>
 306
 307 <!-- ======================================================================= -->
 308 <h3>
 309   <a name="cleanups">Cleanups</a>
 310 </h3>
 311
 312 <div>
 313
 314 <p>A cleanup is extra code which needs to be run as part of unwinding a scope.
 315    C++ destructors are a typical example, but other languages and language
 316    extensions provide a variety of different kinds of cleanups. In general, a
 317    landing pad may need to run arbitrary amounts of cleanup code before actually
 318    entering a catch block. To indicate the presence of cleanups, a
 319    <a href="LangRef.html#i_landingpad"><tt>landingpad</tt> instruction</a>
 320    should have a <i>cleanup</i> clause. Otherwise, the unwinder will not stop at
 321    the landing pad if there are no catches or filters that require it to.</p>
 322
 323 <p><b>Note:</b> Do not allow a new exception to propagate out of the execution
 324    of a cleanup. This can corrupt the internal state of the unwinder.
 325    Different languages describe different high-level semantics for these
 326    situations: for example, C++ requires that the process be terminated, whereas
 327    Ada cancels both exceptions and throws a third.</p>
 328
 329 <p>When all cleanups are finished, if the exception is not handled by the
 330    current function, resume unwinding by calling the
 331    <a href="LangRef.html#i_resume"><tt>resume</tt> instruction</a>, passing in
 332    the result of the <tt>landingpad</tt> instruction for the original landing
 333    pad.</p>
 334
 335 </div>
 336
 337 <!-- ======================================================================= -->
 338 <h3>
 339   <a name="throw_filters">Throw Filters</a>
 340 </h3>
 341
 342 <div>
 343
 344 <p>C++ allows the specification of which exception types may be thrown from a
 345    function. To represent this, a top level landing pad may exist to filter out
 346    invalid types. To express this in LLVM code the
 347    <a href="LangRef.html#i_landingpad"><tt>landingpad</tt> instruction</a> will
 348    have a filter clause. The clause consists of an array of type infos.
 349    <tt>landingpad</tt> will return a negative value if the exception does not
 350    match any of the type infos. If no match is found then a call
 351    to <tt>__cxa_call_unexpected</tt> should be made, otherwise
 352    <tt>_Unwind_Resume</tt>.  Each of these functions requires a reference to the
 353    exception structure.  Note that the most general form of a
 354    <a href="LangRef.html#i_landingpad"><tt>landingpad</tt> instruction</a> can
 355    have any number of catch, cleanup, and filter clauses (though having more
 356    than one cleanup is pointless). The LLVM C++ front-end can generate such
 357    <a href="LangRef.html#i_landingpad"><tt>landingpad</tt> instructions</a> due
 358    to inlining creating nested exception handling scopes.</p>
 359
 360 </div>
 361
 362 <!-- ======================================================================= -->
 363 <h3>
 364   <a name="restrictions">Restrictions</a>
 365 </h3>
 366
 367 <div>
 368
 369 <p>The unwinder delegates the decision of whether to stop in a call frame to
 370    that call frame's language-specific personality function. Not all personality
 371    functions guarantee that they will stop to perform cleanups. For example, the
 372    GNU C++ personality function doesn't do so unless the exception is actually
 373    caught somewhere further up the stack. When using this personality to
 374    implement EH for a language that guarantees that cleanups will always be run
 375    (e.g. Ada), be sure to indicate a catch-all in the
 376    <a href="LangRef.html#i_landingpad"><tt>landingpad</tt> instruction</a>
 377    rather than just cleanups.</p>
 378
 379 <p>In order for inlining to behave correctly, landing pads must be prepared to
 380    handle selector results that they did not originally advertise. Suppose that
 381    a function catches exceptions of type <tt>A</tt>, and it's inlined into a
 382    function that catches exceptions of type <tt>B</tt>. The inliner will update
 383    the <tt>landingpad</tt> instruction for the inlined landing pad to include
 384    the fact that <tt>B</tt> is also caught. If that landing pad assumes that it
 385    will only be entered to catch an <tt>A</tt>, it's in for a rude awakening.
 386    Consequently, landing pads must test for the selector results they understand
 387    and then resume exception propagation with the
 388    <a href="LangRef.html#i_resume"><tt>resume</tt> instruction</a> if none of
 389    the conditions match.</p>
 390
 391 </div>
 392
 393 </div>
 394
 395 <!-- ======================================================================= -->
 396 <h2>
 397   <a name="format_common_intrinsics">Exception Handling Intrinsics</a>
 398 </h2>
 399
 400 <div>
 401
 402 <p>In addition to the
 403    <a href="LangRef.html#i_landingpad"><tt>landingpad</tt></a> and
 404    <a href="LangRef.html#i_resume"><tt>resume</tt></a> instructions, LLVM uses
 405    several intrinsic functions (name prefixed with <i><tt>llvm.eh</tt></i>) to
 406    provide exception handling information at various points in generated
 407    code.</p>
 408
 409 <!-- ======================================================================= -->
 410 <h4>
 411   <a name="llvm_eh_typeid_for">llvm.eh.typeid.for</a>
 412 </h4>
 413
 414 <div>
 415
 416 <pre>
 417   i32 @llvm.eh.typeid.for(i8* %type_info)
 418 </pre>
 419
 420 <p>This intrinsic returns the type info index in the exception table of the
 421    current function.  This value can be used to compare against the result
 422    of <a href="LangRef.html#i_landingpad"><tt>landingpad</tt> instruction</a>.
 423    The single argument is a reference to a type info.</p>
 424
 425 </div>
 426
 427 <!-- ======================================================================= -->
 428 <h4>
 429   <a name="llvm_eh_sjlj_setjmp">llvm.eh.sjlj.setjmp</a>
 430 </h4>
 431
 432 <div>
 433
 434 <pre>
 435   i32 @llvm.eh.sjlj.setjmp(i8* %setjmp_buf)
 436 </pre>
 437
 438 <p>For SJLJ based exception handling, this intrinsic forces register saving for
 439    the current function and stores the address of the following instruction for
 440    use as a destination address
 441    by <a href="#llvm_eh_sjlj_longjmp"><tt>llvm.eh.sjlj.longjmp</tt></a>. The
 442    buffer format and the overall functioning of this intrinsic is compatible
 443    with the GCC <tt>__builtin_setjmp</tt> implementation allowing code built
 444    with the clang and GCC to interoperate.</p>
 445
 446 <p>The single parameter is a pointer to a five word buffer in which the calling
 447    context is saved. The front end places the frame pointer in the first word,
 448    and the target implementation of this intrinsic should place the destination
 449    address for a
 450    <a href="#llvm_eh_sjlj_longjmp"><tt>llvm.eh.sjlj.longjmp</tt></a> in the
 451    second word. The following three words are available for use in a
 452    target-specific manner.</p>
 453
 454 </div>
 455
 456 <!-- ======================================================================= -->
 457 <h4>
 458   <a name="llvm_eh_sjlj_longjmp">llvm.eh.sjlj.longjmp</a>
 459 </h4>
 460
 461 <div>
 462
 463 <pre>
 464   void @llvm.eh.sjlj.longjmp(i8* %setjmp_buf)
 465 </pre>
 466
 467 <p>For SJLJ based exception handling, the <tt>llvm.eh.sjlj.longjmp</tt>
 468    intrinsic is used to implement <tt>__builtin_longjmp()</tt>. The single
 469    parameter is a pointer to a buffer populated
 470    by <a href="#llvm_eh_sjlj_setjmp"><tt>llvm.eh.sjlj.setjmp</tt></a>. The frame
 471    pointer and stack pointer are restored from the buffer, then control is
 472    transferred to the destination address.</p>
 473
 474 </div>
 475 <!-- ======================================================================= -->
 476 <h4>
 477   <a name="llvm_eh_sjlj_lsda">llvm.eh.sjlj.lsda</a>
 478 </h4>
 479
 480 <div>
 481
 482 <pre>
 483   i8* @llvm.eh.sjlj.lsda()
 484 </pre>
 485
 486 <p>For SJLJ based exception handling, the <tt>llvm.eh.sjlj.lsda</tt> intrinsic
 487    returns the address of the Language Specific Data Area (LSDA) for the current
 488    function. The SJLJ front-end code stores this address in the exception
 489    handling function context for use by the runtime.</p>
 490
 491 </div>
 492
 493 <!-- ======================================================================= -->
 494 <h4>
 495   <a name="llvm_eh_sjlj_callsite">llvm.eh.sjlj.callsite</a>
 496 </h4>
 497
 498 <div>
 499
 500 <pre>
 501   void @llvm.eh.sjlj.callsite(i32 %call_site_num)
 502 </pre>
 503
 504 <p>For SJLJ based exception handling, the <tt>llvm.eh.sjlj.callsite</tt>
 505    intrinsic identifies the callsite value associated with the
 506    following <tt>invoke</tt> instruction. This is used to ensure that landing
 507    pad entries in the LSDA are generated in matching order.</p>
 508
 509 </div>
 510
 511 <!-- ======================================================================= -->
 512 <h4>
 513   <a name="llvm_eh_sjlj_dispatchsetup">llvm.eh.sjlj.dispatchsetup</a>
 514 </h4>
 515
 516 <div>
 517
 518 <pre>
 519   void @llvm.eh.sjlj.dispatchsetup(i32 %dispatch_value)
 520 </pre>
 521
 522 <p>For SJLJ based exception handling, the <tt>llvm.eh.sjlj.dispatchsetup</tt>
 523    intrinsic is used by targets to do any unwind edge setup they need. By
 524    default, no action is taken.</p>
 525
 526 </div>
 527
 528 </div>
 529
 530 <!-- ======================================================================= -->
 531 <h2>
 532   <a name="asm">Asm Table Formats</a>
 533 </h2>
 534
 535 <div>
 536
 537 <p>There are two tables that are used by the exception handling runtime to
 538    determine which actions should be taken when an exception is thrown.</p>
 539
 540 <!-- ======================================================================= -->
 541 <h3>
 542   <a name="unwind_tables">Exception Handling Frame</a>
 543 </h3>
 544
 545 <div>
 546
 547 <p>An exception handling frame <tt>eh_frame</tt> is very similar to the unwind
 548    frame used by DWARF debug info. The frame contains all the information
 549    necessary to tear down the current frame and restore the state of the prior
 550    frame. There is an exception handling frame for each function in a compile
 551    unit, plus a common exception handling frame that defines information common
 552    to all functions in the unit.</p>
 553
 554 <!-- Todo - Table details here. -->
 555
 556 </div>
 557
 558 <!-- ======================================================================= -->
 559 <h3>
 560   <a name="exception_tables">Exception Tables</a>
 561 </h3>
 562
 563 <div>
 564
 565 <p>An exception table contains information about what actions to take when an
 566    exception is thrown in a particular part of a function's code. There is one
 567    exception table per function, except leaf functions and functions that have
 568    calls only to non-throwing functions. They do not need an exception
 569    table.</p>
 570
 571 <!-- Todo - Table details here. -->
 572
 573 </div>
 574
 575 </div>
 576
 577 <!-- *********************************************************************** -->
 578
 579 <hr>
 580 <address>
 581   <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
 582   src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
 583   <a href="http://validator.w3.org/check/referer"><img
 584   src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
 585
 586   <a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
 587   <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br>
 588   Last modified: $Date$
 589 </address>
 590
 591 </body>
 592 </html>