forked from OSchip/llvm-project
133 lines
6.4 KiB
HTML
133 lines
6.4 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>Testing LLDB</title>
|
|
</head>
|
|
<body>
|
|
<div class="www_title">
|
|
The <strong>LLDB</strong> Debugger
|
|
</div>
|
|
|
|
<div id="container">
|
|
<div id="content">
|
|
|
|
<!--#include virtual="sidebar.incl"-->
|
|
|
|
<div id="middle">
|
|
<div class="post">
|
|
<h1 class="postheader">Testing LLDB</h1>
|
|
<div class="postcontent">
|
|
<p>
|
|
The LLDB test suite consists of Python scripts located under the
|
|
<tt>test</tt> directory. Each script contains a number of test cases and is usually
|
|
accompanied by a C (C++, ObjC, etc.) source file. Each test first compiles the
|
|
source file and then uses LLDB to debug the resulting executable. The tests verify
|
|
both the LLDB command line interface and the scripting API.
|
|
</p>
|
|
|
|
<p>
|
|
The easiest way to run the LLDB test suite is to use the <tt>check-lldb</tt> build
|
|
target. By default, the <tt>check-lldb</tt> target builds the test programs with
|
|
the same compiler that was used to build LLDB. To build the tests with a different
|
|
compiler, you can set the <tt>LLDB_TEST_COMPILER</tt> CMake variable. It is possible to
|
|
customize the architecture of the test binaries and compiler used by appending -A
|
|
and -C options respectively to the CMake variable <tt>LLDB_TEST_USER_ARGS</tt>. For
|
|
example, to test LLDB against 32-bit binaries
|
|
built with a custom version of clang, do:
|
|
</p>
|
|
<code>
|
|
<br />> cmake -DLLDB_TEST_ARGS="-A i386 -C /path/to/custom/clang" -G Ninja
|
|
<br />> ninja check-lldb
|
|
</code>
|
|
<p>Note that multiple -A and -C flags can be specified to <tt>LLDB_TEST_USER_ARGS</tt>.</p>
|
|
<p>Note that on NetBSD you must export <tt>LD_LIBRARY_PATH=$PWD/lib</tt> in your environment. This is due to lack of
|
|
the <tt>$ORIGIN</tt> linker feature.</p>
|
|
<p>
|
|
In addition to running all the LLDB test suites with the "check-lldb" CMake target above, it is possible to
|
|
run individual LLDB tests. For example, to run the test cases defined in TestInferiorCrashing.py, run:
|
|
</p>
|
|
<code>
|
|
<br />> cd $lldb/test
|
|
<br />> python dotest.py --executable <path-to-lldb> -p TestInferiorCrashing.py
|
|
</code>
|
|
<p>
|
|
In addition to running a test by name, it is also possible to specify a directory path to <tt>dotest.py</tt>
|
|
in order to run all the tests under that directory. For example, to run all the tests under the
|
|
'functionalities/data-formatter' directory, run:
|
|
</p>
|
|
<code>
|
|
<br />> python dotest.py --executable <path-to-lldb> functionalities/data-formatter
|
|
</code>
|
|
<p>
|
|
To dump additional information to <tt>stdout</tt> about how the test harness is driving LLDB, run
|
|
<tt>dotest.py</tt> with the <tt>-t</tt> flag. Many more options that are available. To see a list of all of them, run:
|
|
</p>
|
|
<code>
|
|
<br />> python dotest.py -h
|
|
</code>
|
|
|
|
<p>
|
|
The dotest.py script runs tests in parallel by default.
|
|
To disable the parallel test running feature, use the
|
|
<code>--no-multiprocess</code> flag. The number of
|
|
concurrent tests is controlled by
|
|
the <code>LLDB_TEST_THREADS</code> environment variable
|
|
or the <code>--threads</code> command line parameter.
|
|
The default value is the number of CPU cores on your
|
|
system.
|
|
</p>
|
|
<p>
|
|
The parallel test running feature will handle an
|
|
additional <code>--test-subdir SUBDIR</code> arg. When
|
|
specified, SUBDIR is relative to the root test directory
|
|
and will limit all parallel test running to that
|
|
subdirectory's tree of tests.
|
|
</p>
|
|
<p>
|
|
The parallel test runner will run all tests within a
|
|
given directory serially, but will run multiple
|
|
directories concurrently. Thus, as a test writer, we
|
|
provide serialized test run semantics within a
|
|
directory. Note child directories are considered
|
|
entirely separate, so two child directories could be
|
|
running in parallel with a parent directory.
|
|
</p>
|
|
|
|
<h3>Running the test-suite remotely</h3>
|
|
|
|
<p>
|
|
Running the test-suite remotely is similar to the process of running a local test
|
|
suite, but there are two things to have in mind:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
You must have the <code>lldb-server</code> running on the remote system, ready to
|
|
accept multiple connections. For more information on how to setup remote
|
|
debugging see the <a href="remote.html">Remote debugging</a> page.
|
|
</li>
|
|
<li>
|
|
You must tell the test-suite how to connect to the remote system. This is
|
|
achieved using the <code>--platform-name</code>, <code>--platform-url</code> and
|
|
<code>--platform-working-dir</code> parameters to <code>dotest.py</code>. These
|
|
parameters correspond to the <code>platform select</code> and <code>platform
|
|
connect</code> LLDB commands. You will usually also need to specify the compiler and
|
|
architecture for the remote system.
|
|
</li>
|
|
</ul>
|
|
<p>
|
|
Currently, running the remote test suite is supported only with
|
|
<code>dotest.py</code> (or <code>dosep.py</code> with a single thread), but we
|
|
expect this issue to be addressed in the near future.
|
|
</p>
|
|
|
|
</div>
|
|
<div class="postfooter"></div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</body>
|
|
</html>
|