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> 13 14 <div id="container"> 15 <div id="content"> 16 17 <!--#include virtual="sidebar.incl"--> 18 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> 39 <li><a href="#dataformatters">DataFormatters</a></li> 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> 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> 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 71 class).</p> 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 82 resolve themselves as your program runs. Whether settings breakpoints 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 92 with breakpoints and allows us to do what the user wants.</p> 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 108 logically grouped into a hierarchy.</p> 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 127 are implemented:</p> 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> 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> 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 186 to ask about identifiers it doesn't know about. Once 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 191 up into code that can be run on the process being debugged.</p> 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 202 layer. This layer involves everything from spawning, detaching, 203 joining and killing native in-process threads, to getting 204 current information about the current host.</p> 205 <p>Host functionality includes abstraction layers for:</p> 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 226 commands.</p> 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 266 <p>Utility files should be as stand alone as possible and 267 available for LLDB, plug-ins or related 268 applications to use.</p> 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> 282 </html> 283
