docs/SourceLevelDebugging.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>Source Level Debugging with LLVM</title>
   6   <link rel="stylesheet" href="llvm.css" type="text/css">
   7 </head>
   8 <body>
   9
  10 <div class="doc_title">Source Level Debugging with LLVM</div>
  11
  12 <table border="0" width="100%">
  13 <tr>
  14 <td valign="top">
  15 <ul>
  16
  17   <li><a href="#introduction">Introduction</a>
  18   <ol>
  19     <li><a href="#phil">Philosophy behind LLVM debugging information</a></li>
  20     <li><a href="#debugopt">Debugging optimized code</a></li>
  21     <li><a href="#future">Future work</a></li>
  22   </ol></li>
  23   <li><a href="#llvm-db">Using the <tt>llvm-db</tt> tool</a>
  24   <ol>
  25     <li><a href="#limitations">Limitations of <tt>llvm-db</tt></a></li>
  26     <li><a href="#sample">A sample <tt>llvm-db</tt> session</a></li>
  27     <li><a href="#startup">Starting the debugger</a></li>
  28     <li><a href="#commands">Commands recognized by the debugger</a></li>
  29   </ol></li>
  30
  31   <li><a href="#architecture">Architecture of the LLVM debugger</a>
  32   <ol>
  33     <li><a href="#arch_debugger">The Debugger and InferiorProcess classes</a></li>
  34     <li><a href="#arch_info">The RuntimeInfo, ProgramInfo, and SourceLanguage classes</a></li>
  35     <li><a href="#arch_llvm-db">The <tt>llvm-db</tt> tool</a></li>
  36     <li><a href="#arch_todo">Short-term TODO list</a></li>
  37   </ol></li>
  38
  39   <li><a href="#format">Debugging information format</a>
  40   <ol>
  41     <li><a href="#format_common_anchors">Anchors for global objects</a></li>
  42     <li><a href="#format_common_stoppoint">Representing stopping points in the source program</a></li>
  43     <li><a href="#format_common_lifetime">Object lifetimes and scoping</a></li>
  44     <li><a href="#format_common_descriptors">Object descriptor formats</a>
  45     <ul>
  46       <li><a href="#format_common_source_files">Representation of source files</a></li>
  47       <li><a href="#format_common_program_objects">Representation of program objects</a></li>
  48       <li><a href="#format_common_object_contexts">Program object contexts</a></li>
  49     </ul></li>
  50     <li><a href="#format_common_intrinsics">Debugger intrinsic functions</a></li>
  51     <li><a href="#format_common_tags">Values for debugger tags</a></li>
  52   </ol></li>
  53   <li><a href="#ccxx_frontend">C/C++ front-end specific debug information</a>
  54   <ol>
  55     <li><a href="#ccxx_pse">Program Scope Entries</a>
  56     <ul>
  57       <li><a href="#ccxx_compilation_units">Compilation unit entries</a></li>
  58       <li><a href="#ccxx_modules">Module, namespace, and importing entries</a></li>
  59     </ul></li>
  60     <li><a href="#ccxx_dataobjects">Data objects (program variables)</a></li>
  61   </ol></li>
  62 </ul>
  63 </td>
  64 <td align="right" valign="top">
  65 <img src="img/venusflytrap.jpg" alt="A leafy and green bug eater" width="247"
  66 height="369">
  67 </td>
  68 </tr>
  69 </table>
  70
  71 <div class="doc_author">
  72   <p>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a></p>
  73 </div>
  74
  75
  76 <!-- *********************************************************************** -->
  77 <div class="doc_section"><a name="introduction">Introduction</a></div> <!--
  78 *********************************************************************** -->
  79
  80 <div class="doc_text">
  81
  82 <p>This document is the central repository for all information pertaining to
  83 debug information in LLVM.  It describes the <a href="#llvm-db">user
  84 interface</a> for the <a href="CommandGuide/llvm-db.html"><tt>llvm-db</tt>
  85 tool</a>, which provides a powerful <a href="#llvm-db">source-level debugger</a>
  86 to users of LLVM-based compilers.  It then describes the <a
  87 href="#architecture">various components</a> that make up the debugger and the
  88 libraries which future clients may use.  Finally, it describes the <a
  89 href="#format">actual format that the LLVM debug information</a> takes,
  90 which is useful for those interested in creating front-ends or dealing directly
  91 with the information.</p>
  92
  93 </div>
  94
  95 <!-- ======================================================================= -->
  96 <div class="doc_subsection">
  97   <a name="phil">Philosophy behind LLVM debugging information</a>
  98 </div>
  99
 100 <div class="doc_text">
 101
 102 <p>The idea of the LLVM debugging information is to capture how the important
 103 pieces of the source-language's Abstract Syntax Tree map onto LLVM code.
 104 Several design aspects have shaped the solution that appears here.  The
 105 important ones are:</p>
 106
 107 <ul>
 108 <li>Debugging information should have very little impact on the rest of the
 109 compiler.  No transformations, analyses, or code generators should need to be
 110 modified because of debugging information.</li>
 111
 112 <li>LLVM optimizations should interact in <a href="#debugopt">well-defined and
 113 easily described ways</a> with the debugging information.</li>
 114
 115 <li>Because LLVM is designed to support arbitrary programming languages,
 116 LLVM-to-LLVM tools should not need to know anything about the semantics of the
 117 source-level-language.</li>
 118
 119 <li>Source-level languages are often <b>widely</b> different from one another.
 120 LLVM should not put any restrictions of the flavor of the source-language, and
 121 the debugging information should work with any language.</li>
 122
 123 <li>With code generator support, it should be possible to use an LLVM compiler
 124 to compile a program to native machine code and standard debugging formats.
 125 This allows compatibility with traditional machine-code level debuggers, like
 126 GDB or DBX.</li>
 127
 128 </ul>
 129
 130 <p>The approach used by the LLVM implementation is to use a small set of <a
 131 href="#format_common_intrinsics">intrinsic functions</a> to define a mapping
 132 between LLVM program objects and the source-level objects.  The description of
 133 the source-level program is maintained in LLVM global variables in an <a
 134 href="#ccxx_frontend">implementation-defined format</a> (the C/C++ front-end
 135 currently uses working draft 7 of the <a
 136 href="http://www.eagercon.com/dwarf/dwarf3std.htm">Dwarf 3 standard</a>).</p>
 137
 138 <p>When a program is debugged, the debugger interacts with the user and turns
 139 the stored debug information into source-language specific information.  As
 140 such, the debugger must be aware of the source-language, and is thus tied to a
 141 specific language of family of languages.  The <a href="#llvm-db">LLVM
 142 debugger</a> is designed to be modular in its support for source-languages.</p>
 143
 144 </div>
 145
 146
 147 <!-- ======================================================================= -->
 148 <div class="doc_subsection">
 149   <a name="debugopt">Debugging optimized code</a>
 150 </div>
 151
 152 <div class="doc_text">
 153
 154 <p>An extremely high priority of LLVM debugging information is to make it
 155 interact well with optimizations and analysis.  In particular, the LLVM debug
 156 information provides the following guarantees:</p>
 157
 158 <ul>
 159
 160 <li>LLVM debug information <b>always provides information to accurately read the
 161 source-level state of the program</b>, regardless of which LLVM optimizations
 162 have been run, and without any modification to the optimizations themselves.
 163 However, some optimizations may impact the ability to modify the current state
 164 of the program with a debugger, such as setting program variables, or calling
 165 function that have been deleted.</li>
 166
 167 <li>LLVM optimizations gracefully interact with debugging information.  If they
 168 are not aware of debug information, they are automatically disabled as necessary
 169 in the cases that would invalidate the debug info.  This retains the LLVM
 170 features making it easy to write new transformations.</li>
 171
 172 <li>As desired, LLVM optimizations can be upgraded to be aware of the LLVM
 173 debugging information, allowing them to update the debugging information as they
 174 perform aggressive optimizations.  This means that, with effort, the LLVM
 175 optimizers could optimize debug code just as well as non-debug code.</li>
 176
 177 <li>LLVM debug information does not prevent many important optimizations from
 178 happening (for example inlining, basic block reordering/merging/cleanup, tail
 179 duplication, etc), further reducing the amount of the compiler that eventually
 180 is "aware" of debugging information.</li>
 181
 182 <li>LLVM debug information is automatically optimized along with the rest of the
 183 program, using existing facilities.  For example, duplicate information is
 184 automatically merged by the linker, and unused information is automatically
 185 removed.</li>
 186
 187 </ul>
 188
 189 <p>Basically, the debug information allows you to compile a program with
 190 "<tt>-O0 -g</tt>" and get full debug information, allowing you to arbitrarily
 191 modify the program as it executes from the debugger.  Compiling a program with
 192 "<tt>-O3 -g</tt>" gives you full debug information that is always available and
 193 accurate for reading (e.g., you get accurate stack traces despite tail call
 194 elimination and inlining), but you might lose the ability to modify the program
 195 and call functions where were optimized out of the program, or inlined away
 196 completely.</p>
 197
 198 </div>
 199
 200 <!-- ======================================================================= -->
 201 <div class="doc_subsection">
 202   <a name="future">Future work</a>
 203 </div>
 204
 205 <div class="doc_text">
 206 <p>There are several important extensions that could be eventually added to the
 207 LLVM debugger.  The most important extension would be to upgrade the LLVM code
 208 generators to support debugging information.  This would also allow, for
 209 example, the X86 code generator to emit native objects that contain debugging
 210 information consumable by traditional source-level debuggers like GDB or
 211 DBX.</p>
 212
 213 <p>Additionally, LLVM optimizations can be upgraded to incrementally update the
 214 debugging information, <a href="#commands">new commands</a> can be added to the
 215 debugger, and thread support could be added to the debugger.</p>
 216
 217 <p>The "SourceLanguage" modules provided by <tt>llvm-db</tt> could be
 218 substantially improved to provide good support for C++ language features like
 219 namespaces and scoping rules.</p>
 220
 221 <p>After working with the debugger for a while, perhaps the nicest improvement
 222 would be to add some sort of line editor, such as GNU readline (but one that is
 223 compatible with the LLVM license).</p>
 224
 225 <p>For someone so inclined, it should be straight-forward to write different
 226 front-ends for the LLVM debugger, as the LLVM debugging engine is cleanly
 227 separated from the <tt>llvm-db</tt> front-end.  A new LLVM GUI debugger or IDE
 228 would be nice. :)</p>
 229
 230 </div>
 231
 232 <!-- *********************************************************************** -->
 233 <div class="doc_section">
 234   <a name="llvm-db">Using the <tt>llvm-db</tt> tool</a>
 235 </div>
 236 <!-- *********************************************************************** -->
 237
 238 <div class="doc_text">
 239
 240 <p>The <tt>llvm-db</tt> tool provides a GDB-like interface for source-level
 241 debugging of programs.  This tool provides many standard commands for inspecting
 242 and modifying the program as it executes, loading new programs, single stepping,
 243 placing breakpoints, etc.  This section describes how to use the debugger.</p>
 244
 245 <p><tt>llvm-db</tt> has been designed to be as similar to GDB in its user
 246 interface as possible.  This should make it extremely easy to learn
 247 <tt>llvm-db</tt> if you already know <tt>GDB</tt>.  In general, <tt>llvm-db</tt>
 248 provides the subset of GDB commands that are applicable to LLVM debugging users.
 249 If there is a command missing that make a reasonable amount of sense within the
 250 <a href="#limitations">limitations of <tt>llvm-db</tt></a>, please report it as
 251 a bug or, better yet, submit a patch to add it. :)</p>
 252
 253 </div>
 254
 255 <!-- ======================================================================= -->
 256 <div class="doc_subsection">
 257   <a name="limitations">Limitations of <tt>llvm-db</tt></a>
 258 </div>
 259
 260 <div class="doc_text">
 261
 262 <p><tt>llvm-db</tt> is designed to be modular and easy to extend.  This
 263 extensibility was key to getting the debugger up-and-running quickly, because we
 264 can start with simple-but-unsophisicated implementations of various components.
 265 Because of this, it is currently missing many features, though they should be
 266 easy to add over time (patches welcomed!).  The biggest inherent limitations of
 267 <tt>llvm-db</tt> are currently due to extremely simple <a
 268 href="#arch_debugger">debugger backend</a> (implemented in
 269 "lib/Debugger/UnixLocalInferiorProcess.cpp") which is designed to work without
 270 any cooperation from the code generators.  Because it is so simple, it suffers
 271 from the following inherent limitations:</p>
 272
 273 <ul>
 274
 275 <li>Running a program in <tt>llvm-db</tt> is a bit slower than running it with
 276 <tt>lli</tt> (i.e., in the JIT).</li>
 277
 278 <li>Inspection of the target hardware is not supported.  This means that you
 279 cannot, for example, print the contents of X86 registers.</li>
 280
 281 <li>Inspection of LLVM code is not supported.  This means that you cannot print
 282 the contents of arbitrary LLVM values, or use commands such as <tt>stepi</tt>.
 283 This also means that you cannot debug code without debug information.</li>
 284
 285 <li>Portions of the debugger run in the same address space as the program being
 286 debugged.  This means that memory corruption by the program could trample on
 287 portions of the debugger.</li>
 288
 289 <li>Attaching to existing processes and core files is not currently
 290 supported.</li>
 291
 292 </ul>
 293
 294 <p>That said, the debugger is still quite useful, and all of these limitations
 295 can be eliminated by integrating support for the debugger into the code
 296 generators, and writing a new <a href="#arch_debugger">InferiorProcess</a>
 297 subclass to use it.  See the <a href="#future">future work</a> section for ideas
 298 of how to extend the LLVM debugger despite these limitations.</p>
 299
 300 </div>
 301
 302
 303 <!-- ======================================================================= -->
 304 <div class="doc_subsection">
 305   <a name="sample">A sample <tt>llvm-db</tt> session</a>
 306 </div>
 307
 308 <div class="doc_text">
 309
 310 <p>TODO: this is obviously lame, when more is implemented, this can be much
 311 better.</p>
 312
 313 <pre>
 314 $ <b>llvm-db funccall</b>
 315 llvm-db: The LLVM source-level debugger
 316 Loading program... successfully loaded 'funccall.bc'!
 317 (llvm-db) <b>create</b>
 318 Starting program: funccall.bc
 319 main at funccall.c:9:2
 320 9 ->            q = 0;
 321 (llvm-db) <b>list main</b>
 322 4       void foo() {
 323 5               int t = q;
 324 6               q = t + 1;
 325 7       }
 326 8       int main() {
 327 9 ->            q = 0;
 328 10              foo();
 329 11              q = q - 1;
 330 12
 331 13              return q;
 332 (llvm-db) <b>list</b>
 333 14      }
 334 (llvm-db) <b>step</b>
 335 10 ->           foo();
 336 (llvm-db) <b>s</b>
 337 foo at funccall.c:5:2
 338 5 ->            int t = q;
 339 (llvm-db) <b>bt</b>
 340 #0 ->   0x85ffba0 in foo at funccall.c:5:2
 341 #1      0x85ffd98 in main at funccall.c:10:2
 342 (llvm-db) <b>finish</b>
 343 main at funccall.c:11:2
 344 11 ->           q = q - 1;
 345 (llvm-db) <b>s</b>
 346 13 ->           return q;
 347 (llvm-db) <b>s</b>
 348 The program stopped with exit code 0
 349 (llvm-db) <b>quit</b>
 350 $
 351 </pre>
 352
 353 </div>
 354
 355
 356
 357 <!-- ======================================================================= -->
 358 <div class="doc_subsection">
 359   <a name="startup">Starting the debugger</a>
 360 </div>
 361
 362 <div class="doc_text">
 363
 364 <p>There are three ways to start up the <tt>llvm-db</tt> debugger:</p>
 365
 366 <p>When run with no options, just <tt>llvm-db</tt>, the debugger starts up
 367 without a program loaded at all.  You must use the <a
 368 href="#c_file"><tt>file</tt> command</a> to load a program, and the <a
 369 href="#c_set_args"><tt>set args</tt></a> or <a href="#c_run"><tt>run</tt></a>
 370 commands to specify the arguments for the program.</p>
 371
 372 <p>If you start the debugger with one argument, as <tt>llvm-db
 373 &lt;program&gt;</tt>, the debugger will start up and load in the specified
 374 program.  You can then optionally specify arguments to the program with the <a
 375 href="#c_set_args"><tt>set args</tt></a> or <a href="#c_run"><tt>run</tt></a>
 376 commands.</p>
 377
 378 <p>The third way to start the program is with the <tt>--args</tt> option.  This
 379 option allows you to specify the program to load and the arguments to start out
 380 with.  <!-- No options to <tt>llvm-db</tt> may be specified after the
 381 <tt>-args</tt> option. --> Example use: <tt>llvm-db --args ls /home</tt></p>
 382
 383 </div>
 384
 385 <!-- ======================================================================= -->
 386 <div class="doc_subsection">
 387   <a name="commands">Commands recognized by the debugger</a>
 388 </div>
 389
 390 <div class="doc_text">
 391
 392 <p>FIXME: this needs work obviously.  See the <a
 393 href="http://sources.redhat.com/gdb/documentation/">GDB documentation</a> for
 394 information about what these do, or try '<tt>help [command]</tt>' within
 395 <tt>llvm-db</tt> to get information.</p>
 396
 397 <p>
 398 <h2>General usage:</h2>
 399 <ul>
 400 <li>help [command]</li>
 401 <li>quit</li>
 402 <li><a name="c_file">file</a> [program]</li>
 403 </ul>
 404
 405 <h2>Program inspection and interaction:</h2>
 406 <ul>
 407 <li>create (start the program, stopping it ASAP in <tt>main</tt>)</li>
 408 <li>kill</li>
 409 <li>run [args]</li>
 410 <li>step [num]</li>
 411 <li>next [num]</li>
 412 <li>cont</li>
 413 <li>finish</li>
 414
 415 <li>list [start[, end]]</li>
 416 <li>info source</li>
 417 <li>info sources</li>
 418 <li>info functions</li>
 419 </ul>
 420
 421 <h2>Call stack inspection:</h2>
 422 <ul>
 423 <li>backtrace</li>
 424 <li>up [n]</li>
 425 <li>down [n]</li>
 426 <li>frame [n]</li>
 427 </ul>
 428
 429
 430 <h2>Debugger inspection and interaction:</h2>
 431 <ul>
 432 <li>info target</li>
 433 <li>show prompt</li>
 434 <li>set prompt</li>
 435 <li>show listsize</li>
 436 <li>set listsize</li>
 437 <li>show language</li>
 438 <li>set language</li>
 439 <li>show args</li>
 440 <li>set args [args]</li>
 441 </ul>
 442
 443 <h2>TODO:</h2>
 444 <ul>
 445 <li>info frame</li>
 446 <li>break</li>
 447 <li>print</li>
 448 <li>ptype</li>
 449
 450 <li>info types</li>
 451 <li>info variables</li>
 452 <li>info program</li>
 453
 454 <li>info args</li>
 455 <li>info locals</li>
 456 <li>info catch</li>
 457 <li>... many others</li>
 458 </ul>
 459
 460 </div>
 461
 462 <!-- *********************************************************************** -->
 463 <div class="doc_section">
 464   <a name="architecture">Architecture of the LLVM debugger</a>
 465 </div>
 466 <!-- *********************************************************************** -->
 467
 468 <div class="doc_text">
 469 <p>The LLVM debugger is built out of three distinct layers of software.  These
 470 layers provide clients with different interface options depending on what pieces
 471 of they want to implement themselves, and it also promotes code modularity and
 472 good design.  The three layers are the <a href="#arch_debugger">Debugger
 473 interface</a>, the <a href="#arch_info">"info" interfaces</a>, and the <a
 474 href="#arch_llvm-db"><tt>llvm-db</tt> tool</a> itself.</p>
 475 </div>
 476
 477 <!-- ======================================================================= -->
 478 <div class="doc_subsection">
 479   <a name="arch_debugger">The Debugger and InferiorProcess classes</a>
 480 </div>
 481
 482 <div class="doc_text">
 483 <p>The Debugger class (defined in the <tt>include/llvm/Debugger/</tt> directory)
 484 is a low-level class which is used to maintain information about the loaded
 485 program, as well as start and stop the program running as necessary.  This class
 486 does not provide any high-level analysis or control over the program, only
 487 exposing simple interfaces like <tt>load/unloadProgram</tt>,
 488 <tt>create/killProgram</tt>, <tt>step/next/finish/contProgram</tt>, and
 489 low-level methods for installing breakpoints.</p>
 490
 491 <p>
 492 The Debugger class is itself a wrapper around the lowest-level InferiorProcess
 493 class.  This class is used to represent an instance of the program running under
 494 debugger control.  The InferiorProcess class can be implemented in different
 495 ways for different targets and execution scenarios (e.g., remote debugging).
 496 The InferiorProcess class exposes a small and simple collection of interfaces
 497 which are useful for inspecting the current state of the program (such as
 498 collecting stack trace information, reading the memory image of the process,
 499 etc).  The interfaces in this class are designed to be as low-level and simple
 500 as possible, to make it easy to create new instances of the class.
 501 </p>
 502
 503 <p>
 504 The Debugger class exposes the currently active instance of InferiorProcess
 505 through the <tt>Debugger::getRunningProcess</tt> method, which returns a
 506 <tt>const</tt> reference to the class.  This means that clients of the Debugger
 507 class can only <b>inspect</b> the running instance of the program directly.  To
 508 change the executing process in some way, they must use the interces exposed by
 509 the Debugger class.
 510 </p>
 511 </div>
 512
 513 <!-- ======================================================================= -->
 514 <div class="doc_subsection">
 515   <a name="arch_info">The RuntimeInfo, ProgramInfo, and SourceLanguage classes</a>
 516 </div>
 517
 518 <div class="doc_text">
 519 <p>
 520 The next-highest level of debugger abstraction is provided through the
 521 ProgramInfo, RuntimeInfo, SourceLanguage and related classes (also defined in
 522 the <tt>include/llvm/Debugger/</tt> directory).  These classes efficiently
 523 decode the debugging information and low-level interfaces exposed by
 524 InferiorProcess into a higher-level representation, suitable for analysis by the
 525 debugger.
 526 </p>
 527
 528 <p>
 529 The ProgramInfo class exposes a variety of different kinds of information about
 530 the program objects in the source-level-language.  The SourceFileInfo class
 531 represents a source-file in the program (e.g. a .cpp or .h file).  The
 532 SourceFileInfo class captures information such as which SourceLanguage was used
 533 to compile the file, where the debugger can get access to the actual file text
 534 (which is lazily loaded on demand), etc.  The SourceFunctionInfo class
 535 represents a... <b>FIXME: finish</b>.  The ProgramInfo class provides interfaces
 536 to lazily find and decode the information needed to create the Source*Info
 537 classes requested by the debugger.
 538 </p>
 539
 540 <p>
 541 The RuntimeInfo class exposes information about the currently executed program,
 542 by decoding information from the InferiorProcess and ProgramInfo classes.  It
 543 provides a StackFrame class which provides an easy-to-use interface for
 544 inspecting the current and suspended stack frames in the program.
 545 </p>
 546
 547 <p>
 548 The SourceLanguage class is an abstract interface used by the debugger to
 549 perform all source-language-specific tasks.  For example, this interface is used
 550 by the ProgramInfo class to decode language-specific types and functions and by
 551 the debugger front-end (such as <a href="#arch_llvm-db"><tt>llvm-db</tt></a> to
 552 evaluate source-langauge expressions typed into the debugger.  This class uses
 553 the RuntimeInfo &amp; ProgramInfo classes to get information about the current
 554 execution context and the loaded program, respectively.
 555 </p>
 556
 557 </div>
 558
 559 <!-- ======================================================================= -->
 560 <div class="doc_subsection">
 561   <a name="arch_llvm-db">The <tt>llvm-db</tt> tool</a>
 562 </div>
 563
 564 <div class="doc_text">
 565 <p>
 566 The <tt>llvm-db</tt> is designed to be a debugger providing an interface as <a
 567 href="#llvm-db">similar to GDB</a> as reasonable, but no more so than that.
 568 Because the <a href="#arch_debugger">Debugger</a> and <a
 569 href="#arch_info">info</a> classes implement all of the heavy lifting and
 570 analysis, <tt>llvm-db</tt> (which lives in <tt>llvm/tools/llvm-db</tt>) consists
 571 mainly of of code to interact with the user and parse commands.  The CLIDebugger
 572 constructor registers all of the builtin commands for the debugger, and each
 573 command is implemented as a CLIDebugger::[name]Command method.
 574 </p>
 575 </div>
 576
 577
 578 <!-- ======================================================================= -->
 579 <div class="doc_subsection">
 580   <a name="arch_todo">Short-term TODO list</a>
 581 </div>
 582
 583 <div class="doc_text">
 584
 585 <p>
 586 FIXME: this section will eventually go away.  These are notes to myself of
 587 things that should be implemented, but haven't yet.
 588 </p>
 589
 590 <p>
 591 <b>Breakpoints:</b> Support is already implemented in the 'InferiorProcess'
 592 class, though it hasn't been tested yet.  To finish breakpoint support, we need
 593 to implement breakCommand (which should reuse the linespec parser from the list
 594 command), and handle the fact that 'break foo' or 'break file.c:53' may insert
 595 multiple breakpoints.  Also, if you say 'break file.c:53' and there is no
 596 stoppoint on line 53, the breakpoint should go on the next available line.  My
 597 idea was to have the Debugger class provide a "Breakpoint" class which
 598 encapsulated this messiness, giving the debugger front-end a simple interface.
 599 The debugger front-end would have to map the really complex semantics of
 600 temporary breakpoints and 'conditional' breakpoints onto this intermediate
 601 level. Also, breakpoints should survive as much as possible across program
 602 reloads.
 603 </p>
 604
 605 <p>
 606 <b>UnixLocalInferiorProcess.cpp speedup</b>: There is no reason for the debugged
 607 process to code gen the globals corresponding to debug information.  The
 608 IntrinsicLowering object could instead change descriptors into constant expr
 609 casts of the constant address of the LLVM objects for the descriptors.  This
 610 would also allow us to eliminate the mapping back and forth between physical
 611 addresses that must be done.</p>
 612
 613 <p>
 614 <b>Process deaths</b>: The InferiorProcessDead exception should be extended to
 615 know "how" a process died, i.e., it was killed by a signal.  This is easy to
 616 collect in the UnixLocalInferiorProcess, we just need to represent it.</p>
 617
 618 </div>
 619
 620 <!-- *********************************************************************** -->
 621 <div class="doc_section">
 622   <a name="format">Debugging information format</a>
 623 </div>
 624 <!-- *********************************************************************** -->
 625
 626 <div class="doc_text">
 627
 628 <p>LLVM debugging information has been carefully designed to make it possible
 629 for the optimizer to optimize the program and debugging information without
 630 necessarily having to know anything about debugging information.  In particular,
 631 the global constant merging pass automatically eliminates duplicated debugging
 632 information (often caused by header files), the global dead code elimination
 633 pass automatically deletes debugging information for a function if it decides to
 634 delete the function, and the linker eliminates debug information when it merges
 635 <tt>linkonce</tt> functions.</p>
 636
 637 <p>To do this, most of the debugging information (descriptors for types,
 638 variables, functions, source files, etc) is inserted by the language front-end
 639 in the form of LLVM global variables.  These LLVM global variables are no
 640 different from any other global variables, except that they have a web of LLVM
 641 intrinsic functions that point to them.  If the last references to a particular
 642 piece of debugging information are deleted (for example, by the
 643 <tt>-globaldce</tt> pass), the extraneous debug information will automatically
 644 become dead and be removed by the optimizer.</p>
 645
 646 <p>The debugger is designed to be agnostic about the contents of most of the
 647 debugging information.  It uses a <a href="#arch_info">source-language-specific
 648 module</a> to decode the information that represents variables, types,
 649 functions, namespaces, etc: this allows for arbitrary source-language semantics
 650 and type-systems to be used, as long as there is a module written for the
 651 debugger to interpret the information.</p>
 652
 653 <p>To provide basic functionality, the LLVM debugger does have to make some
 654 assumptions about the source-level language being debugged, though it keeps
 655 these to a minimum.  The only common features that the LLVM debugger assumes
 656 exist are <a href="#format_common_source_files">source files</a>, and <a
 657 href="#format_program_objects">program objects</a>.  These abstract objects are
 658 used by the debugger to form stack traces, show information about local
 659 variables, etc.</p>
 660
 661 <p>This section of the documentation first describes the representation aspects
 662 common to any source-language.  The <a href="#ccxx_frontend">next section</a>
 663 describes the data layout conventions used by the C and C++ front-ends.</p>
 664
 665 </div>
 666
 667 <!-- ======================================================================= -->
 668 <div class="doc_subsection">
 669   <a name="format_common_anchors">Anchors for global objects</a>
 670 </div>
 671
 672 <div class="doc_text">
 673 <p>One important aspect of the LLVM debug representation is that it allows the
 674 LLVM debugger to efficiently index all of the global objects without having the
 675 scan the program.  To do this, all of the global objects use "anchor" globals of
 676 type "<tt>{}</tt>", with designated names.  These anchor objects obviously do
 677 not contain any content or meaning by themselves, but all of the global objects
 678 of a particular type (e.g., source file descriptors) contain a pointer to the
 679 anchor.  This pointer allows the debugger to use def-use chains to find all
 680 global objects of that type.</p>
 681
 682 <p>So far, the following names are recognized as anchors by the LLVM
 683 debugger:</p>
 684
 685 <pre>
 686   %<a href="#format_common_source_files">llvm.dbg.translation_units</a> = linkonce global {} {}
 687   %<a href="#format_program_objects">llvm.dbg.globals</a>         = linkonce global {} {}
 688 </pre>
 689
 690 <p>Using anchors in this way (where the source file descriptor points to the
 691 anchors, as opposed to having a list of source file descriptors) allows for the
 692 standard dead global elimination and merging passes to automatically remove
 693 unused debugging information.  If the globals were kept track of through lists,
 694 there would always be an object pointing to the descriptors, thus would never be
 695 deleted.</p>
 696
 697 </div>
 698
 699 <!-- ======================================================================= -->
 700 <div class="doc_subsection">
 701   <a name="format_common_stoppoint">
 702      Representing stopping points in the source program
 703   </a>
 704 </div>
 705
 706 <div class="doc_text">
 707
 708 <p>LLVM debugger "stop points" are a key part of the debugging representation
 709 that allows the LLVM to maintain simple semantics for <a
 710 href="#debugopt">debugging optimized code</a>.  The basic idea is that the
 711 front-end inserts calls to the <tt>%llvm.dbg.stoppoint</tt> intrinsic function
 712 at every point in the program where the debugger should be able to inspect the
 713 program (these correspond to places the debugger stops when you "<tt>step</tt>"
 714 through it).  The front-end can choose to place these as fine-grained as it
 715 would like (for example, before every subexpression evaluated), but it is
 716 recommended to only put them after every source statement that includes
 717 executable code.</p>
 718
 719 <p>Using calls to this intrinsic function to demark legal points for the
 720 debugger to inspect the program automatically disables any optimizations that
 721 could potentially confuse debugging information.  To non-debug-information-aware
 722 transformations, these calls simply look like calls to an external function,
 723 which they must assume to do anything (including reading or writing to any part
 724 of reachable memory).  On the other hand, it does not impact many optimizations,
 725 such as code motion of non-trapping instructions, nor does it impact
 726 optimization of subexpressions, code duplication transformations, or basic-block
 727 reordering transformations.</p>
 728
 729 <p>An important aspect of the calls to the <tt>%llvm.dbg.stoppoint</tt>
 730 intrinsic is that the function-local debugging information is woven together
 731 with use-def chains.  This makes it easy for the debugger to, for example,
 732 locate the 'next' stop point.  For a concrete example of stop points, see the
 733 example in <a href="#format_common_lifetime">the next section</a>.</p>
 734
 735 </div>
 736
 737
 738 <!-- ======================================================================= -->
 739 <div class="doc_subsection">
 740   <a name="format_common_lifetime">Object lifetimes and scoping</a>
 741 </div>
 742
 743 <div class="doc_text">
 744 <p>In many languages, the local variables in functions can have their lifetime
 745 or scope limited to a subset of a function.  In the C family of languages, for
 746 example, variables are only live (readable and writable) within the source block
 747 that they are defined in.  In functional languages, values are only readable
 748 after they have been defined.  Though this is a very obvious concept, it is also
 749 non-trivial to model in LLVM, because it has no notion of scoping in this sense,
 750 and does not want to be tied to a language's scoping rules.</p>
 751
 752 <p>In order to handle this, the LLVM debug format uses the notion of "regions"
 753 of a function, delineated by calls to intrinsic functions.  These intrinsic
 754 functions define new regions of the program and indicate when the region
 755 lifetime expires.  Consider the following C fragment, for example:</p>
 756
 757 <pre>
 758 1.  void foo() {
 759 2.    int X = ...;
 760 3.    int Y = ...;
 761 4.    {
 762 5.      int Z = ...;
 763 6.      ...
 764 7.    }
 765 8.    ...
 766 9.  }
 767 </pre>
 768
 769 <p>Compiled to LLVM, this function would be represented like this (FIXME: CHECK
 770 AND UPDATE THIS):</p>
 771
 772 <pre>
 773 void %foo() {
 774     %X = alloca int
 775     %Y = alloca int
 776     %Z = alloca int
 777     <a name="#icl_ex_D1">%D1</a> = call {}* %llvm.dbg.func.start(<a href="#format_program_objects">%lldb.global</a>* %d.foo)
 778     %D2 = call {}* <a href="#format_common_stoppoint">%llvm.dbg.stoppoint</a>({}* %D1, uint 2, uint 2, <a href="#format_common_source_files">%lldb.compile_unit</a>* %file)
 779
 780     %D3 = call {}* %llvm.dbg.DEFINEVARIABLE({}* %D2, ...)
 781     <i>;; Evaluate expression on line 2, assigning to X.</i>
 782     %D4 = call {}* <a href="#format_common_stoppoint">%llvm.dbg.stoppoint</a>({}* %D3, uint 3, uint 2, <a href="#format_common_source_files">%lldb.compile_unit</a>* %file)
 783
 784     %D5 = call {}* %llvm.dbg.DEFINEVARIABLE({}* %D4, ...)
 785     <i>;; Evaluate expression on line 3, assigning to Y.</i>
 786     %D6 = call {}* <a href="#format_common_stoppoint">%llvm.dbg.stoppoint</a>({}* %D5, uint 5, uint 4, <a href="#format_common_source_files">%lldb.compile_unit</a>* %file)
 787
 788     <a name="#icl_ex_D1">%D7</a> = call {}* %llvm.region.start({}* %D6)
 789     %D8 = call {}* %llvm.dbg.DEFINEVARIABLE({}* %D7, ...)
 790     <i>;; Evaluate expression on line 5, assigning to Z.</i>
 791     %D9 = call {}* <a href="#format_common_stoppoint">%llvm.dbg.stoppoint</a>({}* %D8, uint 6, uint 4, <a href="#format_common_source_files">%lldb.compile_unit</a>* %file)
 792
 793     <i>;; Code for line 6.</i>
 794     %D10 = call {}* %llvm.region.end({}* %D9)
 795     %D11 = call {}* <a href="#format_common_stoppoint">%llvm.dbg.stoppoint</a>({}* %D10, uint 8, uint 2, <a href="#format_common_source_files">%lldb.compile_unit</a>* %file)
 796
 797     <i>;; Code for line 8.</i>
 798     <a name="#icl_ex_D1">%D12</a> = call {}* %llvm.region.end({}* %D11)
 799     ret void
 800 }
 801 </pre>
 802
 803 <p>This example illustrates a few important details about the LLVM debugging
 804 information.  In particular, it shows how the various intrinsics used are woven
 805 together with def-use and use-def chains, similar to how <a
 806 href="#format_common_anchors">anchors</a> are used with globals.  This allows
 807 the debugger to analyze the relationship between statements, variable
 808 definitions, and the code used to implement the function.</p>
 809
 810 <p>In this example, two explicit regions are defined, one with the <a
 811 href="#icl_ex_D1">definition of the <tt>%D1</tt> variable</a> and one with the
 812 <a href="#icl_ex_D7">definition of <tt>%D7</tt></a>.  In the case of
 813 <tt>%D1</tt>, the debug information indicates that the function whose <a
 814 href="#format_program_objects">descriptor</a> is specified as an argument to the
 815 intrinsic.  This defines a new stack frame whose lifetime ends when the region
 816 is ended by <a href="#icl_ex_D12">the <tt>%D12</tt> call</a>.</p>
 817
 818 <p>Using regions to represent the boundaries of source-level functions allow
 819 LLVM interprocedural optimizations to arbitrarily modify LLVM functions without
 820 having to worry about breaking mapping information between the LLVM code and the
 821 and source-level program.  In particular, the inliner requires no modification
 822 to support inlining with debugging information: there is no explicit correlation
 823 drawn between LLVM functions and their source-level counterparts (note however,
 824 that if the inliner inlines all instances of a non-strong-linkage function into
 825 its caller that it will not be possible for the user to manually invoke the
 826 inlined function from the debugger).</p>
 827
 828 <p>Once the function has been defined, the <a
 829 href="#format_common_stoppoint">stopping point</a> corresponding to line #2 of
 830 the function is encountered.  At this point in the function, <b>no</b> local
 831 variables are live.  As lines 2 and 3 of the example are executed, their
 832 variable definitions are automatically introduced into the program, without the
 833 need to specify a new region.  These variables do not require new regions to be
 834 introduced because they go out of scope at the same point in the program: line
 835 9.</p>
 836
 837 <p>In contrast, the <tt>Z</tt> variable goes out of scope at a different time,
 838 on line 7.  For this reason, it is defined within <a href="#icl_ex_D7">the
 839 <tt>%D7</tt> region</a>, which kills the availability of <tt>Z</tt> before the
 840 code for line 8 is executed.  In this way, regions can support arbitrary
 841 source-language scoping rules, as long as they can only be nested (ie, one scope
 842 cannot partially overlap with a part of another scope).</p>
 843
 844 <p>It is worth noting that this scoping mechanism is used to control scoping of
 845 all declarations, not just variable declarations.  For example, the scope of a
 846 C++ using declaration is controlled with this, and the <tt>llvm-db</tt> C++
 847 support routines could use this to change how name lookup is performed (though
 848 this is not implemented yet).</p>
 849
 850 </div>
 851
 852 <!-- ======================================================================= -->
 853 <div class="doc_subsection">
 854   <a name="format_common_descriptors">Object descriptor formats</a>
 855 </div>
 856
 857 <div class="doc_text">
 858 <p>The LLVM debugger expects the descriptors for program objects to start in a
 859 canonical format, but the descriptors can include additional information
 860 appended at the end that is source-language specific.  All LLVM debugging
 861 information is versioned, allowing backwards compatibility in the case that the
 862 core structures need to change in some way.  Also, all debugging information
 863 objects start with a <a href="#format_common_tags">tag</a> to indicate what type
 864 of object it is.  The source-language is allows to define its own objects, by
 865 using unreserved tag numbers.</p>
 866
 867 <p>The lowest-level descriptor are those describing <a
 868 href="#format_common_source_files">the files containing the program source
 869 code</a>, as most other descriptors (sometimes indirectly) refer to them.
 870 </p>
 871 </div>
 872
 873
 874 <!-- ------------------------------------------------------------------------ ->
 875 <div class="doc_subsubsection">
 876   <a name="format_common_source_files">Representation of source files</a>
 877 </div>
 878
 879 <div class="doc_text">
 880 <p>
 881 Source file descriptors are patterned after the Dwarf "compile_unit" object.
 882 The descriptor currently is defined to have at least the following LLVM
 883 type entries:</p>
 884
 885 <pre>
 886 %lldb.compile_unit = type {
 887        uint,                 <i>;; Tag: <a href="#tag_compile_unit">LLVM_COMPILE_UNIT</a></i>
 888        ushort,               <i>;; LLVM debug version number</i>
 889        ushort,               <i>;; Dwarf language identifier</i>
 890        sbyte*,               <i>;; Filename</i>
 891        sbyte*,               <i>;; Working directory when compiled</i>
 892        sbyte*                <i>;; Producer of the debug information</i>
 893 }
 894 </pre>
 895
 896 <p>
 897 These descriptors contain the version number for the debug info, a source
 898 language ID for the file (we use the Dwarf 3.0 ID numbers, such as
 899 <tt>DW_LANG_C89</tt>, <tt>DW_LANG_C_plus_plus</tt>, <tt>DW_LANG_Cobol74</tt>,
 900 etc), three strings describing the filename, working directory of the compiler,
 901 and an identifier string for the compiler that produced it.  Note that actual
 902 compile_unit declarations must also include an <a
 903 href="#format_common_anchors">anchor</a> to <tt>llvm.dbg.translation_units</tt>,
 904 but it is not specified where the anchor is to be located.  Here is an example
 905 descriptor:
 906 </p>
 907
 908 <p><pre>
 909 %arraytest_source_file = internal constant %lldb.compile_unit {
 910     <a href="#tag_compile_unit">uint 17</a>,                                                      ; Tag value
 911     ushort 0,                                                     ; Version #0
 912     ushort 1,                                                     ; DW_LANG_C89
 913     sbyte* getelementptr ([12 x sbyte]* %.str_1, long 0, long 0), ; filename
 914     sbyte* getelementptr ([12 x sbyte]* %.str_2, long 0, long 0), ; working dir
 915     sbyte* getelementptr ([12 x sbyte]* %.str_3, long 0, long 0), ; producer
 916     {}* %llvm.dbg.translation_units                               ; Anchor
 917 }
 918 %.str_1 = internal constant [12 x sbyte] c"arraytest.c\00"
 919 %.str_2 = internal constant [12 x sbyte] c"/home/sabre\00"
 920 %.str_3 = internal constant [12 x sbyte] c"llvmgcc 3.4\00"
 921 </pre></p>
 922
 923 <p>
 924 Note that the LLVM constant merging pass should eliminate duplicate copies of
 925 the strings that get emitted to each translation unit, such as the producer.
 926 </p>
 927
 928 </div>
 929
 930
 931 <!-- ----------------------------------------------------------------------- -->
 932 <div class="doc_subsubsection">
 933   <a name="format_program_objects">Representation of program objects</a>
 934 </div>
 935
 936 <div class="doc_text">
 937 <p>
 938 The LLVM debugger needs to know about some source-language program objects, in
 939 order to build stack traces, print information about local variables, and other
 940 related activities.  The LLVM debugger differentiates between three different
 941 types of program objects: subprograms (functions, messages, methods, etc),
 942 variables (locals and globals), and others.  Because source-languages have
 943 widely varying forms of these objects, the LLVM debugger expects only a few
 944 fields in the descriptor for each object:
 945 </p>
 946
 947 <pre>
 948 %lldb.object = type {
 949        uint,                  <i>;; <a href="#format_common_tag">A tag</a></i>
 950        <i>any</i>*,                  <i>;; The <a href="#format_common_object_contexts">context</a> for the object</i>
 951        sbyte*                 <i>;; The object 'name'</i>
 952 }
 953 </pre>
 954
 955 <p>The first field contains a tag for the descriptor.  The second field contains
 956 either a pointer to the descriptor for the containing <a
 957 href="#format_common_source_files">source file</a>, or it contains a pointer to
 958 another program object whose context pointer eventually reaches a source file.
 959 Through this <a href="#format_common_object_contexts">context</a> pointer, the
 960 LLVM debugger can establish the debug version number of the object.</p>
 961
 962 <p>The third field contains a string that the debugger can use to identify the
 963 object if it does not contain explicit support for the source-language in use
 964 (ie, the 'unknown' source language handler uses this string).  This should be
 965 some sort of unmangled string that corresponds to the object, but it is a
 966 quality of implementation issue what exactly it contains (it is legal, though
 967 not useful, for all of these strings to be null).</p>
 968
 969 <p>Note again that descriptors can be extended to include
 970 source-language-specific information in addition to the fields required by the
 971 LLVM debugger.  See the <a href="#ccxx_descriptors">section on the C/C++
 972 front-end</a> for more information.  Also remember that global objects
 973 (functions, selectors, global variables, etc) must contain an <a
 974 href="format_common_anchors">anchor</a> to the <tt>llvm.dbg.globals</tt>
 975 variable.</p>
 976 </div>
 977
 978
 979 <!-- ======================================================================= -->
 980 <div class="doc_subsection">
 981   <a name="format_common_object_contexts">Program object contexts</a>
 982 </div>
 983
 984 <div class="doc_text">
 985 <pre>
 986 Allow source-language specific contexts, use to identify namespaces etc
 987 Must end up in a source file descriptor.
 988 Debugger core ignores all unknown context objects.
 989 </pre>
 990 </div>
 991
 992 <!-- ======================================================================= -->
 993 <div class="doc_subsection">
 994   <a name="format_common_intrinsics">Debugger intrinsic functions</a>
 995 </div>
 996
 997 <div class="doc_text">
 998 <pre>
 999 Define each intrinsics, as an extension of the language reference manual.
1000
1001 llvm.dbg.stoppoint
1002 llvm.dbg.region.start
1003 llvm.dbg.region.end
1004 llvm.dbg.function.start
1005 llvm.dbg.declare
1006 </pre>
1007 </div>
1008
1009 <!-- ======================================================================= -->
1010 <div class="doc_subsection">
1011   <a name="format_common_tags">Values for debugger tags</a>
1012 </div>
1013
1014 <div class="doc_text">
1015
1016 <p>Happen to be the same value as the similarly named Dwarf-3 tags, this may
1017 change in the future.</p>
1018
1019 <pre>
1020   <a name="tag_compile_unit">LLVM_COMPILE_UNIT</a>     : 17
1021   <a name="tag_subprogram">LLVM_SUBPROGRAM</a>       : 46
1022   <a name="tag_variable">LLVM_VARIABLE</a>         : 52
1023 <!--  <a name="tag_formal_parameter">LLVM_FORMAL_PARAMETER :  5-->
1024 </pre>
1025 </div>
1026
1027
1028
1029 <!-- *********************************************************************** -->
1030 <div class="doc_section">
1031   <a name="ccxx_frontend">C/C++ front-end specific debug information</a>
1032 </div>
1033
1034 <div class="doc_text">
1035
1036 <p>The C and C++ front-ends represent information about the program in a format
1037 that is effectively identical to <a
1038 href="http://www.eagercon.com/dwarf/dwarf3std.htm">Dwarf 3.0</a> in terms of
1039 information content.  This allows code generators to trivially support native
1040 debuggers by generating standard dwarf information, and contains enough
1041 information for non-dwarf targets to translate it as needed.</p>
1042
1043 <p>The basic debug information required by the debugger is (intentionally)
1044 designed to be as minimal as possible.  This basic information is so minimal
1045 that it is unlikely that <b>any</b> source-language could be adequately
1046 described by it.  Because of this, the debugger format was designed for
1047 extension to support source-language-specific information.  The extended
1048 descriptors are read and interpreted by the <a
1049 href="#arch_info">language-specific</a> modules in the debugger if there is
1050 support available, otherwise it is ignored.</p>
1051
1052 <p>This section describes the extensions used to represent C and C++ programs.
1053 Other languages could pattern themselves after this (which itself is tuned to
1054 representing programs in the same way that Dwarf 3 does), or they could choose
1055 to provide completely different extensions if they don't fit into the Dwarf
1056 model.  As support for debugging information gets added to the various LLVM
1057 source-language front-ends, the information used should be documented here.</p>
1058
1059 </div>
1060
1061 <!-- ======================================================================= -->
1062 <div class="doc_subsection">
1063   <a name="ccxx_pse">Program Scope Entries</a>
1064 </div>
1065
1066 <div class="doc_text">
1067 <p>TODO</p>
1068 </div>
1069
1070 <!-- -------------------------------------------------------------------------->
1071 <div class="doc_subsubsection">
1072   <a name="ccxx_compilation_units">Compilation unit entries</a>
1073 </div>
1074
1075 <div class="doc_text">
1076 <p>
1077 Translation units do not add any information over the standard <a
1078 href="#format_common_source_files">source file representation</a> already
1079 expected by the debugger.  As such, it uses descriptors of the type specified,
1080 with a trailing <a href="#format_common_anchors">anchor</a>.
1081 </p>
1082 </div>
1083
1084 <!-- -------------------------------------------------------------------------->
1085 <div class="doc_subsubsection">
1086   <a name="ccxx_modules">Module, namespace, and importing entries</a>
1087 </div>
1088
1089 <div class="doc_text">
1090 <p>TODO</p>
1091 </div>
1092
1093 <!-- ======================================================================= -->
1094 <div class="doc_subsection">
1095   <a name="ccxx_dataobjects">Data objects (program variables)</a>
1096 </div>
1097
1098 <div class="doc_text">
1099 <p>TODO</p>
1100 </div>
1101
1102
1103 <!-- *********************************************************************** -->
1104
1105 <hr>
1106 <address>
1107   <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
1108   src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
1109   <a href="http://validator.w3.org/check/referer"><img
1110   src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"></a>
1111
1112   <a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
1113   <a href="http://llvm.cs.uiuc.edu">LLVM Compiler Infrastructure</a><br>
1114   Last modified: $Date$
1115 </address>
1116
1117 </body>
1118 </html>