lldb/www/test.html - llvm-project - Git at Google

 <!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 />&gt; cmake -DLLDB_TEST_ARGS="-A i386 -C /path/to/custom/clang" -G Ninja
               <br />&gt; 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 />&gt; cd $lldb/test
               <br />&gt; python dotest.py --executable &lt;path-to-lldb&gt;  -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 />&gt; python dotest.py --executable &lt;path-to-lldb&gt; 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 />&gt; 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>
	<!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>