Gitiles
Code Review Sign In
gerrit-public.fairphone.software / fp2-dev / platform / external / lldb / 854bb53438d1e966d468795b983de79f5f5605ab / . / www / architecture.html
blob: 287a5a377f1c721e75856d99b5d27a1aecc72179 [file] [log] [blame]
Greg Clayton854bb532010-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>
13
14<div id="container">
15 <div id="content">
16 <!--#include virtual="leftmenu.html.incl"-->
17 <div id="middle">
18 <div class="post">
19 <h1 class ="postheader">Architecture</h1>
20 <div class="postcontent">
21
22 <p>LLDB is a large and complex codebase. This section will help you become more familiar with
23 the pieces that make up LLDB and give a general overview of the general architecture.</p>
24 </div>
25 <div class="postfooter"></div>
26 </div>
27 <div class="post">
28 <h1 class ="postheader">Code Layout</h1>
29 <div class="postcontent">
30
31 <p>LLDB has many code groupings that makeup the source base:</p>
32 <ul>
33 <li><a href="#api">API</a></li>
34 <li><a href="#breakpoint">Breakpoint</a></li>
35 <li><a href="#commands">Commands</a></li>
36 <li><a href="#core">Core</a></li>
37 <li><a href="#expression">Expression</a></li>
38 <li><a href="#host">Host</a></li>
39 <li><a href="#interpreter">Interpreter</a></li>
40 <li><a href="#symbol">Symbol</a></li>
41 <li><a href="#targ">Target</a></li>
42 <li><a href="#utility">Utility</a></li>
43 </ul>
44 </div>
45 <div class="postfooter"></div>
46 </div>
47 <a name="api"></a>
48 <div class="post">
49 <h1 class ="postheader">API</h1>
50 <div class="postcontent">
51
52 <p>The API folder contains the public interface to LLDB.</p>
53 <p>We are currently vending a C++ API. In order to be able to add
54 methods to this API and allow people to link to our classes,
55 we have certain rules that we must follow:</p>
56 <ul>
57 <li>Classes can't inherit from any other classes.</li>
58 <li>Classes can't contain virtual methods.</li>
59 <li>Classes should be compatible with script bridging utilities like <a href="http://www.swig.org/">swig</a>.</li>
60 <li>Classes should be lighweight and be backed by a single object pointer, shared pointer or global variable in the lldb_private.</li>
61 <li>The interface should be as minimal as possible in order to give a complete API.</li>
62 </ul>
63 <p>By adhering to these rules we should be able to continue to
64 vend a C++ API, and make changes to the API as any additional
65 methods added to these classes will just be a dynamic loader
66 lookup and they won't affect the class layout (since they
67 aren't virtual methods, and no members can be added to the
68 class).
69 </div>
70 <div class="postfooter"></div>
71 </div>
72 <a name="breakpoint"></a>
73 <div class="post">
74 <h1 class ="postheader">Breakpoint</h1>
75 <div class="postcontent">
76
77 <p>A collection of classes that implement our breakpoint classes.
78 Breakpoints are resolved symbolically and always continue to
79 resolve themselves as your program runs. Wether settings breakpoints
80 by file and line, by symbol name, by symbol regular expression,
81 or by address, breakpoints will keep trying to resolve new locations
82 each time shared libraries are loaded. Breakpoints will of course
83 unresolve themselves when shared libraries are unloaded. Breakpoints
84 can also be scoped to be set only in a specific shared library. By
85 default, breakpoints can be set in any shared library and will continue
86 to attempt to be resolved with each shared library load.</p>
87 <p>Breakpoint options can be set on the breakpoint,
88 or on the individual locations. This allows flexibility when dealing
89 with breakpoints and allows us to do what the user wants.
90 </div>
91 <div class="postfooter"></div>
92 </div>
93 <a name="commands"></a>
94 <div class="post">
95 <h1 class ="postheader">Commands</h1>
96 <div class="postcontent">
97
98 <p>The command source files represent objects that implement
99 the functionality for all textual commands available
100 in our command line interface.</p>
101 <p>Every command is backed by a <b>lldb_private::CommandObject</b>
102 or <b>lldb_private::CommandObjectMultiword</b> object.</p>
103 <p><b>lldb_private::CommandObjectMultiword</b> are commands that
104 have subcommands and allow command line commands to be
105 logically grouped into a hiearchy.
106 <p><b>lldb_private::CommandObject</b> command line commands
107 are the objects that implement the functionality of the
108 command. They can optionally define
109 options for themselves, as well as group those options into
110 logical groups that can go together. The help system is
111 tied into these objects and can extract the syntax and
112 option groupings to display appropriate help for each
113 command.</p>
114 </div>
115 <div class="postfooter"></div>
116 </div>
117 <a name="core"></a>
118 <div class="post">
119 <h1 class ="postheader">Core</h1>
120 <div class="postcontent">
121
122 <p>The Core source files contain basic functionality that
123 is required in the debugger. A wide variety of classes
124 are implemented:
125
126 <ul>
127 <li>Address (section offset addressing)</li>
128 <li>AddressRange</li>
129 <li>Architecture specification</li>
130 <li>Broadcaster / Event / Listener </li>
131 <li>Communication classes that use Connection objects</li>
132 <li>Uniqued C strings</li>
133 <li>Data extraction</li>
134 <li>File specifications</li>
135 <li>Mangled names</li>
136 <li>Regular expressions</li>
137 <li>Source manager</li>
138 <li>Streams</li>
139 <li>Value objects</li>
140 </ul>
141 </div>
142 <div class="postfooter"></div>
143 </div>
144 <a name="expression"></a>
145 <div class="post">
146 <h1 class ="postheader">Expression</h1>
147 <div class="postcontent">
148
149 <p>Expression parsing files cover everything from evaluating
150 DWARF expressions, to evaluating expressions using
151 Clang.</p>
152 <p>The DWARF expression parser has been heavily modified to
153 support type promotion, new opcodes needed for evaluating
154 expressions with symbolic variable references (expression local variables,
155 program variables), and other operators required by
156 typical expressions such as assign, address of, float/double/long
157 double floating point values, casting, and more. The
158 DWARF expression parser uses a stack of lldb_private::Value
159 objects. These objects know how to do the standard C type
160 promotion, and allow for symbolic references to variables
161 in the program and in the LLDB process (expression local
162 and expression global variables).</p>
163 <p>The expression parser uses a full instance of the Clang
164 compiler in order to accurately evaluate expressions.
165 Hooks have been put into Clang so that the compiler knows
166 to ask about indentifiers it doesn't know about. Once
167 expressions have be compiled into an AST, we can then
168 traverse this AST and either generate a DWARF expression
169 that contains simple opcodes that can be quickly re-evaluated
170 each time an expression needs to be evaluated, or JIT'ed
171 up into code that can be run on the process being debugged.
172 </div>
173 <div class="postfooter"></div>
174 </div>
175 <a name="host"></a>
176 <div class="post">
177 <h1 class ="postheader">Host</h1>
178 <div class="postcontent">
179
180 <p>LLDB tries to abstract itself from the host upon which
181 it is currently running by providing a host abstraction
182 layer This layer involves everything from spawning, detaching,
183 joing and killing native in process threads, to getting
184 current information about the current host.</p>
185 <p>Host functionality includes abstraction layers for:
186 <ul>
187 <li>Mutexes</li>
188 <li>Conditions</li>
189 <li>Timing functions</li>
190 <li>Thread functions</li>
191 <li>Host target triple</li>
192 <li>Host child process notifications</li>
193 <li>Host specific types</li>
194 </ul>
195 </div>
196 <div class="postfooter"></div>
197 </div>
198 <a name="interpreter"></a>
199 <div class="post">
200 <h1 class ="postheader">Interpreter</h1>
201 <div class="postcontent">
202
203 <p>The interpreter classes are the classes responsible for
204 being the base classes needed for each command object,
205 and is responsible for tracking and running command line
206 commands.
207 </div>
208 <div class="postfooter"></div>
209 </div>
210 <a name="symbol"></a>
211 <div class="post">
212 <h1 class ="postheader">Symbol</h1>
213 <div class="postcontent">
214 <p>Symbol classes involve everything needed in order to parse
215 object files and debug symbols. All the needed classes
216 for compilation units (code and debug info for a source file),
217 functions, lexical blocks within functions, inlined
218 functions, types, declaration locations, and variables
219 are in this section.</p>
220 </div>
221 <div class="postfooter"></div>
222 </div>
223 <a name="targ"></a>
224 <div class="post">
225 <h1 class ="postheader">Target</h1>
226 <div class="postcontent">
227
228 <p>Classes that are related to a debug target include:</p>
229 <ul>
230 <li>Target</li>
231 <li>Process</li>
232 <li>Thread</li>
233 <li>Stack frames</li>
234 <li>Stack frame registers</li>
235 <li>ABI for function calling in process being debugged</li>
236 <li>Execution context batons</li>
237 </ul>
238 </div>
239 <div class="postfooter"></div>
240 </div>
241 <a name="utility"></a>
242 <div class="post">
243 <h1 class ="postheader">Utility</h1>
244 <div class="postcontent">
245
246 <p>Utility files should be as stand alone as possible are
247 are available for LLDB and any plug-ins or related
248 applications to use.<\p>
249 <p>Files found in the Utility section include:</p>
250 <ul>
251 <li>Pseudo-terminal support</li>
252 <li>Register numbering for specific architectures.</li>
253 <li>String data extractors</li>
254 </ul>
255 </div>
256 <div class="postfooter"></div>
257 </div>
258 </div>
259 </div>
260</div>
261</body>
262</html>