blob: e4fe32175c3604a557ea369748932b02556a5609 [file] [log] [blame]
<!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 as well as the
class represeting the debugger it self (Debugger). A
wide variety of classes are implemented:
</p>
<ul>
<li>Address (section offset addressing)</li>
<li>AddressRange</li>
<li>Broadcaster / Event / Listener </li>
<li>Communication classes that use Connection objects</li>
<li>Mangled names</li>
<li>Source manager</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 includes functionality, whose
implementation varies wildly from host to host.
</p>
<p>Host functionality includes abstraction layers for:</p>
<ul>
<li>Information about the host system (triple, list of running processes, etc.)</li>
<li>Launching processes</li>
<li>Various OS primitives like pipes and sockets</li>
</ul>
<p>
It also includes the base classes of the
NativeProcess/Thread hierarchy, which is used by
lldb-server.
</p>
</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>
This module contains the lowest layers of LLDB. A
lot of these classes don't really have anything to
do with debugging -- they are just there because the
higher layers of the debugger use these clasess
to implement their functionality. Others are data
structures used in many other parts of the debugger
(TraceOptions). Most of the functionality in this
module could be useful in an application that is
<strong>not</strong> a debugger; however, providing
a general purpose C++ library is an explicit
non-goal of this module.
</p>
<p>
This module provides following functionality:
</p>
<ul>
<li>Abstract path manipulation (FileSpec)</li>
<li>Architecture specification</li>
<li>Data buffers (DataBuffer, DataEncoder, DataExtractor)</li>
<li>Logging</li>
<li>Structured data manipulation (JSON)</li>
<li>Streams</li>
<li>Timers</li>
<li>etc.</li>
</ul>
<p>
For historic reasons, some of this functionality
overlaps that which is provided by the LLVM support
library.
</p>
</div>
<div class="postfooter"></div>
</div>
</div>
</div>
</div>
</body>
</html>