Greg Clayton | 854bb53 | 2010-06-10 02:48:57 +0000 | [diff] [blame] | 1 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
| 2 | <html xmlns="http://www.w3.org/1999/xhtml">
|
| 3 | <head>
|
| 4 | <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
|
| 5 | <link href="style.css" rel="stylesheet" type="text/css" />
|
| 6 | <title>LLDB Architecture</title>
|
| 7 | </head>
|
| 8 |
|
| 9 | <body>
|
| 10 | <div class="www_title">
|
| 11 | The <strong>LLDB</strong> Debugger
|
| 12 | </div>
|
Eric Christopher | b7eb709 | 2010-06-10 05:35:26 +0000 | [diff] [blame] | 13 |
|
Greg Clayton | 854bb53 | 2010-06-10 02:48:57 +0000 | [diff] [blame] | 14 | <div id="container">
|
| 15 | <div id="content">
|
Chris Lattner | 3cc7b7f | 2010-06-11 23:07:14 +0000 | [diff] [blame] | 16 |
|
| 17 | <!--#include virtual="sidebar.incl"-->
|
| 18 |
|
Greg Clayton | 854bb53 | 2010-06-10 02:48:57 +0000 | [diff] [blame] | 19 | <div id="middle">
|
| 20 | <div class="post">
|
| 21 | <h1 class ="postheader">Architecture</h1>
|
| 22 | <div class="postcontent">
|
| 23 |
|
| 24 | <p>LLDB is a large and complex codebase. This section will help you become more familiar with
|
| 25 | the pieces that make up LLDB and give a general overview of the general architecture.</p>
|
| 26 | </div>
|
| 27 | <div class="postfooter"></div>
|
| 28 | </div>
|
| 29 | <div class="post">
|
| 30 | <h1 class ="postheader">Code Layout</h1>
|
| 31 | <div class="postcontent">
|
| 32 |
|
| 33 | <p>LLDB has many code groupings that makeup the source base:</p>
|
| 34 | <ul>
|
| 35 | <li><a href="#api">API</a></li>
|
| 36 | <li><a href="#breakpoint">Breakpoint</a></li>
|
| 37 | <li><a href="#commands">Commands</a></li>
|
| 38 | <li><a href="#core">Core</a></li>
|
Enrico Granata | 4922935 | 2013-01-29 00:42:12 +0000 | [diff] [blame] | 39 | <li><a href="#dataformatters">DataFormatters</a></li>
|
Greg Clayton | 854bb53 | 2010-06-10 02:48:57 +0000 | [diff] [blame] | 40 | <li><a href="#expression">Expression</a></li>
|
| 41 | <li><a href="#host">Host</a></li>
|
| 42 | <li><a href="#interpreter">Interpreter</a></li>
|
| 43 | <li><a href="#symbol">Symbol</a></li>
|
| 44 | <li><a href="#targ">Target</a></li>
|
| 45 | <li><a href="#utility">Utility</a></li>
|
| 46 | </ul>
|
| 47 | </div>
|
| 48 | <div class="postfooter"></div>
|
| 49 | </div>
|
| 50 | <a name="api"></a>
|
| 51 | <div class="post">
|
| 52 | <h1 class ="postheader">API</h1>
|
| 53 | <div class="postcontent">
|
| 54 |
|
| 55 | <p>The API folder contains the public interface to LLDB.</p>
|
| 56 | <p>We are currently vending a C++ API. In order to be able to add
|
| 57 | methods to this API and allow people to link to our classes,
|
| 58 | we have certain rules that we must follow:</p>
|
| 59 | <ul>
|
| 60 | <li>Classes can't inherit from any other classes.</li>
|
| 61 | <li>Classes can't contain virtual methods.</li>
|
| 62 | <li>Classes should be compatible with script bridging utilities like <a href="http://www.swig.org/">swig</a>.</li>
|
Enrico Granata | f812f62 | 2013-05-31 22:54:23 +0000 | [diff] [blame] | 63 | <li>Classes should be lightweight and be backed by a single member. Pointers (or shared pointers) are the preferred choice since they allow changing the contents of the backend without affecting the public object layout.</li>
|
Greg Clayton | 854bb53 | 2010-06-10 02:48:57 +0000 | [diff] [blame] | 64 | <li>The interface should be as minimal as possible in order to give a complete API.</li>
|
| 65 | </ul>
|
| 66 | <p>By adhering to these rules we should be able to continue to
|
| 67 | vend a C++ API, and make changes to the API as any additional
|
| 68 | methods added to these classes will just be a dynamic loader
|
| 69 | lookup and they won't affect the class layout (since they
|
| 70 | aren't virtual methods, and no members can be added to the
|
Benjamin Kramer | 46a8cf3 | 2010-06-10 08:12:17 +0000 | [diff] [blame] | 71 | class).</p>
|
Greg Clayton | 854bb53 | 2010-06-10 02:48:57 +0000 | [diff] [blame] | 72 | </div>
|
| 73 | <div class="postfooter"></div>
|
| 74 | </div>
|
| 75 | <a name="breakpoint"></a>
|
| 76 | <div class="post">
|
| 77 | <h1 class ="postheader">Breakpoint</h1>
|
| 78 | <div class="postcontent">
|
| 79 |
|
| 80 | <p>A collection of classes that implement our breakpoint classes.
|
| 81 | Breakpoints are resolved symbolically and always continue to
|
Jason Molenda | 602ce7e | 2010-06-10 08:23:00 +0000 | [diff] [blame] | 82 | resolve themselves as your program runs. Whether settings breakpoints
|
Greg Clayton | 854bb53 | 2010-06-10 02:48:57 +0000 | [diff] [blame] | 83 | by file and line, by symbol name, by symbol regular expression,
|
| 84 | or by address, breakpoints will keep trying to resolve new locations
|
| 85 | each time shared libraries are loaded. Breakpoints will of course
|
| 86 | unresolve themselves when shared libraries are unloaded. Breakpoints
|
| 87 | can also be scoped to be set only in a specific shared library. By
|
| 88 | default, breakpoints can be set in any shared library and will continue
|
| 89 | to attempt to be resolved with each shared library load.</p>
|
| 90 | <p>Breakpoint options can be set on the breakpoint,
|
| 91 | or on the individual locations. This allows flexibility when dealing
|
Benjamin Kramer | 46a8cf3 | 2010-06-10 08:12:17 +0000 | [diff] [blame] | 92 | with breakpoints and allows us to do what the user wants.</p>
|
Greg Clayton | 854bb53 | 2010-06-10 02:48:57 +0000 | [diff] [blame] | 93 | </div>
|
| 94 | <div class="postfooter"></div>
|
| 95 | </div>
|
| 96 | <a name="commands"></a>
|
| 97 | <div class="post">
|
| 98 | <h1 class ="postheader">Commands</h1>
|
| 99 | <div class="postcontent">
|
| 100 |
|
| 101 | <p>The command source files represent objects that implement
|
| 102 | the functionality for all textual commands available
|
| 103 | in our command line interface.</p>
|
| 104 | <p>Every command is backed by a <b>lldb_private::CommandObject</b>
|
| 105 | or <b>lldb_private::CommandObjectMultiword</b> object.</p>
|
| 106 | <p><b>lldb_private::CommandObjectMultiword</b> are commands that
|
| 107 | have subcommands and allow command line commands to be
|
Caroline Tice | f2f64f2 | 2011-01-07 17:16:03 +0000 | [diff] [blame] | 108 | logically grouped into a hierarchy.</p>
|
Greg Clayton | 854bb53 | 2010-06-10 02:48:57 +0000 | [diff] [blame] | 109 | <p><b>lldb_private::CommandObject</b> command line commands
|
| 110 | are the objects that implement the functionality of the
|
| 111 | command. They can optionally define
|
| 112 | options for themselves, as well as group those options into
|
| 113 | logical groups that can go together. The help system is
|
| 114 | tied into these objects and can extract the syntax and
|
| 115 | option groupings to display appropriate help for each
|
| 116 | command.</p>
|
| 117 | </div>
|
| 118 | <div class="postfooter"></div>
|
| 119 | </div>
|
| 120 | <a name="core"></a>
|
| 121 | <div class="post">
|
| 122 | <h1 class ="postheader">Core</h1>
|
| 123 | <div class="postcontent">
|
| 124 |
|
| 125 | <p>The Core source files contain basic functionality that
|
| 126 | is required in the debugger. A wide variety of classes
|
Benjamin Kramer | 46a8cf3 | 2010-06-10 08:12:17 +0000 | [diff] [blame] | 127 | are implemented:</p>
|
Greg Clayton | 854bb53 | 2010-06-10 02:48:57 +0000 | [diff] [blame] | 128 |
|
| 129 | <ul>
|
| 130 | <li>Address (section offset addressing)</li>
|
| 131 | <li>AddressRange</li>
|
| 132 | <li>Architecture specification</li>
|
| 133 | <li>Broadcaster / Event / Listener </li>
|
| 134 | <li>Communication classes that use Connection objects</li>
|
| 135 | <li>Uniqued C strings</li>
|
| 136 | <li>Data extraction</li>
|
| 137 | <li>File specifications</li>
|
| 138 | <li>Mangled names</li>
|
| 139 | <li>Regular expressions</li>
|
| 140 | <li>Source manager</li>
|
| 141 | <li>Streams</li>
|
| 142 | <li>Value objects</li>
|
| 143 | </ul>
|
| 144 | </div>
|
| 145 | <div class="postfooter"></div>
|
| 146 | </div>
|
Enrico Granata | 4922935 | 2013-01-29 00:42:12 +0000 | [diff] [blame] | 147 | <a name="dataformatters"></a>
|
| 148 | <div class="post">
|
| 149 | <h1 class ="postheader">DataFormatters</h1>
|
| 150 | <div class="postcontent">
|
| 151 |
|
| 152 | <p>A collection of classes that implement the data formatters subsystem.</p>
|
| 153 | <p>The main entry point for interacting with the LLDB data formatters is the DataVisualization class. It provides
|
| 154 | a relatively stable front-end interface to ask questions of the data formatters regardless of the internal implementation.</p>
|
| 155 | <p>For people actively maintaining the data formatters subsystem itself, however, the FormatManager class is the relevant point of entry.
|
| 156 | This class is subject to more frequent changes as the formatters evolve. Currently, it provides a thin caching layer on top of a list of categories
|
| 157 | that each export a group of formatters.
|
| 158 | </p>
|
| 159 | <p>From an end-user perspective, the "type" LLDB command is the point of access to the data formatters. A large group of generally-useful formatters
|
| 160 | is provided by default and loaded upon debugger startup.
|
| 161 | </div>
|
| 162 | <div class="postfooter"></div>
|
| 163 | </div>
|
Greg Clayton | 854bb53 | 2010-06-10 02:48:57 +0000 | [diff] [blame] | 164 | <a name="expression"></a>
|
| 165 | <div class="post">
|
| 166 | <h1 class ="postheader">Expression</h1>
|
| 167 | <div class="postcontent">
|
| 168 |
|
| 169 | <p>Expression parsing files cover everything from evaluating
|
| 170 | DWARF expressions, to evaluating expressions using
|
| 171 | Clang.</p>
|
| 172 | <p>The DWARF expression parser has been heavily modified to
|
| 173 | support type promotion, new opcodes needed for evaluating
|
| 174 | expressions with symbolic variable references (expression local variables,
|
| 175 | program variables), and other operators required by
|
| 176 | typical expressions such as assign, address of, float/double/long
|
| 177 | double floating point values, casting, and more. The
|
| 178 | DWARF expression parser uses a stack of lldb_private::Value
|
| 179 | objects. These objects know how to do the standard C type
|
| 180 | promotion, and allow for symbolic references to variables
|
| 181 | in the program and in the LLDB process (expression local
|
| 182 | and expression global variables).</p>
|
| 183 | <p>The expression parser uses a full instance of the Clang
|
| 184 | compiler in order to accurately evaluate expressions.
|
| 185 | Hooks have been put into Clang so that the compiler knows
|
Chris Lattner | ba6d3bb | 2010-06-11 22:52:46 +0000 | [diff] [blame] | 186 | to ask about identifiers it doesn't know about. Once
|
Greg Clayton | 854bb53 | 2010-06-10 02:48:57 +0000 | [diff] [blame] | 187 | expressions have be compiled into an AST, we can then
|
| 188 | traverse this AST and either generate a DWARF expression
|
| 189 | that contains simple opcodes that can be quickly re-evaluated
|
| 190 | each time an expression needs to be evaluated, or JIT'ed
|
Benjamin Kramer | 46a8cf3 | 2010-06-10 08:12:17 +0000 | [diff] [blame] | 191 | up into code that can be run on the process being debugged.</p>
|
Greg Clayton | 854bb53 | 2010-06-10 02:48:57 +0000 | [diff] [blame] | 192 | </div>
|
| 193 | <div class="postfooter"></div>
|
| 194 | </div>
|
| 195 | <a name="host"></a>
|
| 196 | <div class="post">
|
| 197 | <h1 class ="postheader">Host</h1>
|
| 198 | <div class="postcontent">
|
| 199 |
|
| 200 | <p>LLDB tries to abstract itself from the host upon which
|
| 201 | it is currently running by providing a host abstraction
|
Chris Lattner | ba6d3bb | 2010-06-11 22:52:46 +0000 | [diff] [blame] | 202 | layer. This layer involves everything from spawning, detaching,
|
| 203 | joining and killing native in-process threads, to getting
|
Greg Clayton | 854bb53 | 2010-06-10 02:48:57 +0000 | [diff] [blame] | 204 | current information about the current host.</p>
|
Benjamin Kramer | 46a8cf3 | 2010-06-10 08:12:17 +0000 | [diff] [blame] | 205 | <p>Host functionality includes abstraction layers for:</p>
|
Greg Clayton | 854bb53 | 2010-06-10 02:48:57 +0000 | [diff] [blame] | 206 | <ul>
|
| 207 | <li>Mutexes</li>
|
| 208 | <li>Conditions</li>
|
| 209 | <li>Timing functions</li>
|
| 210 | <li>Thread functions</li>
|
| 211 | <li>Host target triple</li>
|
| 212 | <li>Host child process notifications</li>
|
| 213 | <li>Host specific types</li>
|
| 214 | </ul>
|
| 215 | </div>
|
| 216 | <div class="postfooter"></div>
|
| 217 | </div>
|
| 218 | <a name="interpreter"></a>
|
| 219 | <div class="post">
|
| 220 | <h1 class ="postheader">Interpreter</h1>
|
| 221 | <div class="postcontent">
|
| 222 |
|
| 223 | <p>The interpreter classes are the classes responsible for
|
| 224 | being the base classes needed for each command object,
|
| 225 | and is responsible for tracking and running command line
|
Benjamin Kramer | 46a8cf3 | 2010-06-10 08:12:17 +0000 | [diff] [blame] | 226 | commands.</p>
|
Greg Clayton | 854bb53 | 2010-06-10 02:48:57 +0000 | [diff] [blame] | 227 | </div>
|
| 228 | <div class="postfooter"></div>
|
| 229 | </div>
|
| 230 | <a name="symbol"></a>
|
| 231 | <div class="post">
|
| 232 | <h1 class ="postheader">Symbol</h1>
|
| 233 | <div class="postcontent">
|
| 234 | <p>Symbol classes involve everything needed in order to parse
|
| 235 | object files and debug symbols. All the needed classes
|
| 236 | for compilation units (code and debug info for a source file),
|
| 237 | functions, lexical blocks within functions, inlined
|
| 238 | functions, types, declaration locations, and variables
|
| 239 | are in this section.</p>
|
| 240 | </div>
|
| 241 | <div class="postfooter"></div>
|
| 242 | </div>
|
| 243 | <a name="targ"></a>
|
| 244 | <div class="post">
|
| 245 | <h1 class ="postheader">Target</h1>
|
| 246 | <div class="postcontent">
|
| 247 |
|
| 248 | <p>Classes that are related to a debug target include:</p>
|
| 249 | <ul>
|
| 250 | <li>Target</li>
|
| 251 | <li>Process</li>
|
| 252 | <li>Thread</li>
|
| 253 | <li>Stack frames</li>
|
| 254 | <li>Stack frame registers</li>
|
| 255 | <li>ABI for function calling in process being debugged</li>
|
| 256 | <li>Execution context batons</li>
|
| 257 | </ul>
|
| 258 | </div>
|
| 259 | <div class="postfooter"></div>
|
| 260 | </div>
|
| 261 | <a name="utility"></a>
|
| 262 | <div class="post">
|
| 263 | <h1 class ="postheader">Utility</h1>
|
| 264 | <div class="postcontent">
|
| 265 |
|
Christopher Friesen | 236d842 | 2010-06-12 03:34:21 +0000 | [diff] [blame] | 266 | <p>Utility files should be as stand alone as possible and
|
| 267 | available for LLDB, plug-ins or related
|
Eric Christopher | b7eb709 | 2010-06-10 05:35:26 +0000 | [diff] [blame] | 268 | applications to use.</p>
|
Greg Clayton | 854bb53 | 2010-06-10 02:48:57 +0000 | [diff] [blame] | 269 | <p>Files found in the Utility section include:</p>
|
| 270 | <ul>
|
| 271 | <li>Pseudo-terminal support</li>
|
| 272 | <li>Register numbering for specific architectures.</li>
|
| 273 | <li>String data extractors</li>
|
| 274 | </ul>
|
| 275 | </div>
|
| 276 | <div class="postfooter"></div>
|
| 277 | </div>
|
| 278 | </div>
|
| 279 | </div>
|
| 280 | </div>
|
| 281 | </body>
|
Eric Christopher | b7eb709 | 2010-06-10 05:35:26 +0000 | [diff] [blame] | 282 | </html>
|