<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 <ahref="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>
<divclass="postfooter"></div>
</div>
<aname="breakpoint"></a>
<divclass="post">
<h1class ="postheader">Breakpoint</h1>
<divclass="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>
<divclass="postfooter"></div>
</div>
<aname="commands"></a>
<divclass="post">
<h1class ="postheader">Commands</h1>
<divclass="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>
<divclass="postfooter"></div>
</div>
<aname="core"></a>
<divclass="post">
<h1class ="postheader">Core</h1>
<divclass="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>
<divclass="postfooter"></div>
</div>
<aname="dataformatters"></a>
<divclass="post">
<h1class ="postheader">DataFormatters</h1>
<divclass="postcontent">
<p>A collection of classes that implement the data formatters subsystem.</p>
