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