forked from OSchip/llvm-project
282 lines
12 KiB
HTML
282 lines
12 KiB
HTML
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
|
||
|
|
<link href="../style.css" rel="stylesheet" type="text/css" />
|
||
|
|
<title>LLDB Architecture</title>
|
||
|
|
</head>
|
||
|
|
|
||
|
|
<body>
|
||
|
|
<div class="www_title">
|
||
|
|
<strong>LLDB</strong>'s Architecture
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<div id="container">
|
||
|
|
<div id="content">
|
||
|
|
|
||
|
|
<!--#include virtual="../sidebar.incl"-->
|
||
|
|
|
||
|
|
<div id="middle">
|
||
|
|
<div class="post">
|
||
|
|
<h1 class ="postheader">Architecture</h1>
|
||
|
|
<div class="postcontent">
|
||
|
|
|
||
|
|
<p>LLDB is a large and complex codebase. This section will help you become more familiar with
|
||
|
|
the pieces that make up LLDB and give a general overview of the general architecture.</p>
|
||
|
|
</div>
|
||
|
|
<div class="postfooter"></div>
|
||
|
|
</div>
|
||
|
|
<div class="post">
|
||
|
|
<h1 class ="postheader">Code Layout</h1>
|
||
|
|
<div class="postcontent">
|
||
|
|
|
||
|
|
<p>LLDB has many code groupings that makeup the source base:</p>
|
||
|
|
<ul>
|
||
|
|
<li><a href="#api">API</a></li>
|
||
|
|
<li><a href="#breakpoint">Breakpoint</a></li>
|
||
|
|
<li><a href="#commands">Commands</a></li>
|
||
|
|
<li><a href="#core">Core</a></li>
|
||
|
|
<li><a href="#dataformatters">DataFormatters</a></li>
|
||
|
|
<li><a href="#expression">Expression</a></li>
|
||
|
|
<li><a href="#host">Host</a></li>
|
||
|
|
<li><a href="#interpreter">Interpreter</a></li>
|
||
|
|
<li><a href="#symbol">Symbol</a></li>
|
||
|
|
<li><a href="#targ">Target</a></li>
|
||
|
|
<li><a href="#utility">Utility</a></li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
<div class="postfooter"></div>
|
||
|
|
</div>
|
||
|
|
<a name="api"></a>
|
||
|
|
<div class="post">
|
||
|
|
<h1 class ="postheader">API</h1>
|
||
|
|
<div class="postcontent">
|
||
|
|
|
||
|
|
<p>The API folder contains the public interface to LLDB.</p>
|
||
|
|
<p>We are currently vending a C++ API. In order to be able to add
|
||
|
|
methods to this API and allow people to link to our classes,
|
||
|
|
we have certain rules that we must follow:</p>
|
||
|
|
<ul>
|
||
|
|
<li>Classes can't inherit from any other classes.</li>
|
||
|
|
<li>Classes can't contain virtual methods.</li>
|
||
|
|
<li>Classes should be compatible with script bridging utilities like <a href="http://www.swig.org/">swig</a>.</li>
|
||
|
|
<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>
|
||
|
|
<li>The interface should be as minimal as possible in order to give a complete API.</li>
|
||
|
|
</ul>
|
||
|
|
<p>By adhering to these rules we should be able to continue to
|
||
|
|
vend a C++ API, and make changes to the API as any additional
|
||
|
|
methods added to these classes will just be a dynamic loader
|
||
|
|
lookup and they won't affect the class layout (since they
|
||
|
|
aren't virtual methods, and no members can be added to the
|
||
|
|
class).</p>
|
||
|
|
</div>
|
||
|
|
<div class="postfooter"></div>
|
||
|
|
</div>
|
||
|
|
<a name="breakpoint"></a>
|
||
|
|
<div class="post">
|
||
|
|
<h1 class ="postheader">Breakpoint</h1>
|
||
|
|
<div class="postcontent">
|
||
|
|
|
||
|
|
<p>A collection of classes that implement our breakpoint classes.
|
||
|
|
Breakpoints are resolved symbolically and always continue to
|
||
|
|
resolve themselves as your program runs. Whether settings breakpoints
|
||
|
|
by file and line, by symbol name, by symbol regular expression,
|
||
|
|
or by address, breakpoints will keep trying to resolve new locations
|
||
|
|
each time shared libraries are loaded. Breakpoints will of course
|
||
|
|
unresolve themselves when shared libraries are unloaded. Breakpoints
|
||
|
|
can also be scoped to be set only in a specific shared library. By
|
||
|
|
default, breakpoints can be set in any shared library and will continue
|
||
|
|
to attempt to be resolved with each shared library load.</p>
|
||
|
|
<p>Breakpoint options can be set on the breakpoint,
|
||
|
|
or on the individual locations. This allows flexibility when dealing
|
||
|
|
with breakpoints and allows us to do what the user wants.</p>
|
||
|
|
</div>
|
||
|
|
<div class="postfooter"></div>
|
||
|
|
</div>
|
||
|
|
<a name="commands"></a>
|
||
|
|
<div class="post">
|
||
|
|
<h1 class ="postheader">Commands</h1>
|
||
|
|
<div class="postcontent">
|
||
|
|
|
||
|
|
<p>The command source files represent objects that implement
|
||
|
|
the functionality for all textual commands available
|
||
|
|
in our command line interface.</p>
|
||
|
|
<p>Every command is backed by a <b>lldb_private::CommandObject</b>
|
||
|
|
or <b>lldb_private::CommandObjectMultiword</b> object.</p>
|
||
|
|
<p><b>lldb_private::CommandObjectMultiword</b> are commands that
|
||
|
|
have subcommands and allow command line commands to be
|
||
|
|
logically grouped into a hierarchy.</p>
|
||
|
|
<p><b>lldb_private::CommandObject</b> command line commands
|
||
|
|
are the objects that implement the functionality of the
|
||
|
|
command. They can optionally define
|
||
|
|
options for themselves, as well as group those options into
|
||
|
|
logical groups that can go together. The help system is
|
||
|
|
tied into these objects and can extract the syntax and
|
||
|
|
option groupings to display appropriate help for each
|
||
|
|
command.</p>
|
||
|
|
</div>
|
||
|
|
<div class="postfooter"></div>
|
||
|
|
</div>
|
||
|
|
<a name="core"></a>
|
||
|
|
<div class="post">
|
||
|
|
<h1 class ="postheader">Core</h1>
|
||
|
|
<div class="postcontent">
|
||
|
|
|
||
|
|
<p>The Core source files contain basic functionality that
|
||
|
|
is required in the debugger. A wide variety of classes
|
||
|
|
are implemented:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li>Address (section offset addressing)</li>
|
||
|
|
<li>AddressRange</li>
|
||
|
|
<li>Architecture specification</li>
|
||
|
|
<li>Broadcaster / Event / Listener </li>
|
||
|
|
<li>Communication classes that use Connection objects</li>
|
||
|
|
<li>Uniqued C strings</li>
|
||
|
|
<li>Data extraction</li>
|
||
|
|
<li>File specifications</li>
|
||
|
|
<li>Mangled names</li>
|
||
|
|
<li>Regular expressions</li>
|
||
|
|
<li>Source manager</li>
|
||
|
|
<li>Streams</li>
|
||
|
|
<li>Value objects</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
<div class="postfooter"></div>
|
||
|
|
</div>
|
||
|
|
<a name="dataformatters"></a>
|
||
|
|
<div class="post">
|
||
|
|
<h1 class ="postheader">DataFormatters</h1>
|
||
|
|
<div class="postcontent">
|
||
|
|
|
||
|
|
<p>A collection of classes that implement the data formatters subsystem.</p>
|
||
|
|
<p>Data formatters provide a set of user-tweakable hooks in the ValueObjects world that allow
|
||
|
|
to customize presentation aspects of variables. While users interact with formatters mostly through the
|
||
|
|
<code>type</code> command, inside LLDB there are a few layers to the implementation: DataVisualization at the highest
|
||
|
|
end of the spectrum, backed by classes implementing individual formatters, matching rules, ...</p>
|
||
|
|
|
||
|
|
<p>For a general user-level introduction to data formatters, you can look <a href="../varformats.html">here</a>.
|
||
|
|
<p>More details on the architecture are to be found <a href="../architecture/varformats.html">here</a>.
|
||
|
|
</div>
|
||
|
|
<div class="postfooter"></div>
|
||
|
|
</div>
|
||
|
|
<a name="expression"></a>
|
||
|
|
<div class="post">
|
||
|
|
<h1 class ="postheader">Expression</h1>
|
||
|
|
<div class="postcontent">
|
||
|
|
|
||
|
|
<p>Expression parsing files cover everything from evaluating
|
||
|
|
DWARF expressions, to evaluating expressions using
|
||
|
|
Clang.</p>
|
||
|
|
<p>The DWARF expression parser has been heavily modified to
|
||
|
|
support type promotion, new opcodes needed for evaluating
|
||
|
|
expressions with symbolic variable references (expression local variables,
|
||
|
|
program variables), and other operators required by
|
||
|
|
typical expressions such as assign, address of, float/double/long
|
||
|
|
double floating point values, casting, and more. The
|
||
|
|
DWARF expression parser uses a stack of lldb_private::Value
|
||
|
|
objects. These objects know how to do the standard C type
|
||
|
|
promotion, and allow for symbolic references to variables
|
||
|
|
in the program and in the LLDB process (expression local
|
||
|
|
and expression global variables).</p>
|
||
|
|
<p>The expression parser uses a full instance of the Clang
|
||
|
|
compiler in order to accurately evaluate expressions.
|
||
|
|
Hooks have been put into Clang so that the compiler knows
|
||
|
|
to ask about identifiers it doesn't know about. Once
|
||
|
|
expressions have be compiled into an AST, we can then
|
||
|
|
traverse this AST and either generate a DWARF expression
|
||
|
|
that contains simple opcodes that can be quickly re-evaluated
|
||
|
|
each time an expression needs to be evaluated, or JIT'ed
|
||
|
|
up into code that can be run on the process being debugged.</p>
|
||
|
|
</div>
|
||
|
|
<div class="postfooter"></div>
|
||
|
|
</div>
|
||
|
|
<a name="host"></a>
|
||
|
|
<div class="post">
|
||
|
|
<h1 class ="postheader">Host</h1>
|
||
|
|
<div class="postcontent">
|
||
|
|
|
||
|
|
<p>LLDB tries to abstract itself from the host upon which
|
||
|
|
it is currently running by providing a host abstraction
|
||
|
|
layer. This layer involves everything from spawning, detaching,
|
||
|
|
joining and killing native in-process threads, to getting
|
||
|
|
current information about the current host.</p>
|
||
|
|
<p>Host functionality includes abstraction layers for:</p>
|
||
|
|
<ul>
|
||
|
|
<li>Mutexes</li>
|
||
|
|
<li>Conditions</li>
|
||
|
|
<li>Timing functions</li>
|
||
|
|
<li>Thread functions</li>
|
||
|
|
<li>Host target triple</li>
|
||
|
|
<li>Host child process notifications</li>
|
||
|
|
<li>Host specific types</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
<div class="postfooter"></div>
|
||
|
|
</div>
|
||
|
|
<a name="interpreter"></a>
|
||
|
|
<div class="post">
|
||
|
|
<h1 class ="postheader">Interpreter</h1>
|
||
|
|
<div class="postcontent">
|
||
|
|
|
||
|
|
<p>The interpreter classes are the classes responsible for
|
||
|
|
being the base classes needed for each command object,
|
||
|
|
and is responsible for tracking and running command line
|
||
|
|
commands.</p>
|
||
|
|
</div>
|
||
|
|
<div class="postfooter"></div>
|
||
|
|
</div>
|
||
|
|
<a name="symbol"></a>
|
||
|
|
<div class="post">
|
||
|
|
<h1 class ="postheader">Symbol</h1>
|
||
|
|
<div class="postcontent">
|
||
|
|
<p>Symbol classes involve everything needed in order to parse
|
||
|
|
object files and debug symbols. All the needed classes
|
||
|
|
for compilation units (code and debug info for a source file),
|
||
|
|
functions, lexical blocks within functions, inlined
|
||
|
|
functions, types, declaration locations, and variables
|
||
|
|
are in this section.</p>
|
||
|
|
</div>
|
||
|
|
<div class="postfooter"></div>
|
||
|
|
</div>
|
||
|
|
<a name="targ"></a>
|
||
|
|
<div class="post">
|
||
|
|
<h1 class ="postheader">Target</h1>
|
||
|
|
<div class="postcontent">
|
||
|
|
|
||
|
|
<p>Classes that are related to a debug target include:</p>
|
||
|
|
<ul>
|
||
|
|
<li>Target</li>
|
||
|
|
<li>Process</li>
|
||
|
|
<li>Thread</li>
|
||
|
|
<li>Stack frames</li>
|
||
|
|
<li>Stack frame registers</li>
|
||
|
|
<li>ABI for function calling in process being debugged</li>
|
||
|
|
<li>Execution context batons</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
<div class="postfooter"></div>
|
||
|
|
</div>
|
||
|
|
<a name="utility"></a>
|
||
|
|
<div class="post">
|
||
|
|
<h1 class ="postheader">Utility</h1>
|
||
|
|
<div class="postcontent">
|
||
|
|
|
||
|
|
<p>Utility files should be as stand alone as possible and
|
||
|
|
available for LLDB, plug-ins or related
|
||
|
|
applications to use.</p>
|
||
|
|
<p>Files found in the Utility section include:</p>
|
||
|
|
<ul>
|
||
|
|
<li>Pseudo-terminal support</li>
|
||
|
|
<li>Register numbering for specific architectures.</li>
|
||
|
|
<li>String data extractors</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
<div class="postfooter"></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|