10 The LLDB test suite consists of three different kinds of test:
12 * **Unit tests**: written in C++ using the googletest unit testing library.
13 * **Shell tests**: Integration tests that test the debugger through the command
14 line. These tests interact with the debugger either through the command line
15 driver or through ``lldb-test`` which is a tool that exposes the internal
16 data structures in an easy-to-parse way for testing. Most people will know
17 these as *lit tests* in LLVM, although lit is the test driver and ShellTest
18 is the test format that uses ``RUN:`` lines. `FileCheck
19 <https://llvm.org/docs/CommandGuide/FileCheck.html>`_ is used to verify
21 * **API tests**: Integration tests that interact with the debugger through the
22 SB API. These are written in Python and use LLDB's ``dotest.py`` testing
23 framework on top of Python's `unittest2
24 <https://docs.python.org/2/library/unittest.html>`_.
26 All three test suites use ``lit`` (`LLVM Integrated Tester
27 <https://llvm.org/docs/CommandGuide/lit.html>`_ ) as the test driver. The test
28 suites can be run as a whole or separately.
34 Unit tests are located under ``lldb/unittests``. If it's possible to test
35 something in isolation or as a single unit, you should make it a unit test.
37 Often you need instances of the core objects such as a debugger, target or
38 process, in order to test something meaningful. We already have a handful of
39 tests that have the necessary boiler plate, but this is something we could
40 abstract away and make it more user friendly.
45 Shell tests are located under ``lldb/test/Shell``. These tests are generally
46 built around checking the output of ``lldb`` (the command line driver) or
47 ``lldb-test`` using ``FileCheck``. Shell tests are generally small and fast to
48 write because they require little boilerplate.
50 ``lldb-test`` is a relatively new addition to the test suite. It was the first
51 tool that was added that is designed for testing. Since then it has been
52 continuously extended with new subcommands, improving our test coverage. Among
53 other things you can use it to query lldb for symbol files, for object files
56 Obviously shell tests are great for testing the command line driver itself or
57 the subcomponents already exposed by lldb-test. But when it comes to LLDB's
58 vast functionality, most things can be tested both through the driver as well
59 as the Python API. For example, to test setting a breakpoint, you could do it
60 from the command line driver with ``b main`` or you could use the SB API and do
61 something like ``target.BreakpointCreateByName`` [#]_.
63 A good rule of thumb is to prefer shell tests when what is being tested is
64 relatively simple. Expressivity is limited compared to the API tests, which
65 means that you have to have a well-defined test scenario that you can easily
66 match with ``FileCheck``.
68 Another thing to consider are the binaries being debugged, which we call
69 inferiors. For shell tests, they have to be relatively simple. The
70 ``dotest.py`` test framework has extensive support for complex build scenarios
71 and different variants, which is described in more detail below, while shell
72 tests are limited to single lines of shell commands with compiler and linker
75 On the same topic, another interesting aspect of the shell tests is that there
76 you can often get away with a broken or incomplete binary, whereas the API
77 tests almost always require a fully functional executable. This enables testing
78 of (some) aspects of handling of binaries with non-native architectures or
81 Finally, the shell tests always run in batch mode. You start with some input
82 and the test verifies the output. The debugger can be sensitive to its
83 environment, such as the platform it runs on. It can be hard to express
84 that the same test might behave slightly differently on macOS and Linux.
85 Additionally, the debugger is an interactive tool, and the shell test provide
86 no good way of testing those interactive aspects, such as tab completion for
92 API tests are located under ``lldb/test/API``. They are run with the
93 ``dotest.py``. Tests are written in Python and test binaries (inferiors) are
94 compiled with Make. The majority of API tests are end-to-end tests that compile
95 programs from source, run them, and debug the processes.
97 As mentioned before, ``dotest.py`` is LLDB's testing framework. The
98 implementation is located under ``lldb/packages/Python/lldbsuite``. We have
99 several extensions and custom test primitives on top of what's offered by
100 `unittest2 <https://docs.python.org/2/library/unittest.html>`_. Those can be
102 `lldbtest.py <https://github.com/llvm/llvm-project/blob/main/lldb/packages/Python/lldbsuite/test/lldbtest.py>`_.
104 Below is the directory layout of the `example API test
105 <https://github.com/llvm/llvm-project/tree/main/lldb/test/API/sample_test>`_.
106 The test directory will always contain a python file, starting with ``Test``.
107 Most of the tests are structured as a binary being debugged, so there will be
108 one or more source files and a ``Makefile``.
114 ├── TestSampleTest.py
117 Let's start with the Python test file. Every test is its own class and can have
118 one or more test methods, that start with ``test_``. Many tests define
119 multiple test methods and share a bunch of common code. For example, for a
120 fictive test that makes sure we can set breakpoints we might have one test
121 method that ensures we can set a breakpoint by address, on that sets a
122 breakpoint by name and another that sets the same breakpoint by file and line
123 number. The setup, teardown and everything else other than setting the
124 breakpoint could be shared.
126 Our testing framework also has a bunch of utilities that abstract common
127 operations, such as creating targets, setting breakpoints etc. When code is
128 shared across tests, we extract it into a utility in ``lldbutil``. It's always
129 worth taking a look at `lldbutil
130 <https://github.com/llvm/llvm-project/blob/main/lldb/packages/Python/lldbsuite/test/lldbutil.py>`_
131 to see if there's a utility to simplify some of the testing boiler plate.
132 Because we can't always audit every existing test, this is doubly true when
133 looking at an existing test for inspiration.
135 It's possible to skip or `XFAIL
136 <https://ftp.gnu.org/old-gnu/Manuals/dejagnu-1.3/html_node/dejagnu_6.html>`_
137 tests using decorators. You'll see them a lot. The debugger can be sensitive to
138 things like the architecture, the host and target platform, the compiler
139 version etc. LLDB comes with a range of predefined decorators for these
144 @expectedFailureAll(archs=["aarch64"], oslist=["linux"]
146 Another great thing about these decorators is that they're very easy to extend,
147 it's even possible to define a function in a test case that determines whether
148 the test should be run or not.
152 @expectedFailure(checking_function_name)
154 In addition to providing a lot more flexibility when it comes to writing the
155 test, the API test also allow for much more complex scenarios when it comes to
156 building inferiors. Every test has its own ``Makefile``, most of them only a
157 few lines long. A shared ``Makefile`` (``Makefile.rules``) with about a
158 thousand lines of rules takes care of most if not all of the boiler plate,
159 while individual make files can be used to build more advanced tests.
161 Here's an example of a simple ``Makefile`` used by the example test.
166 CFLAGS_EXTRAS := -std=c99
168 include Makefile.rules
170 Finding the right variables to set can be tricky. You can always take a look at
171 `Makefile.rules <https://github.com/llvm/llvm-project/blob/main/lldb/packages/Python/lldbsuite/test/make/Makefile.rules>`_
172 but often it's easier to find an existing ``Makefile`` that does something
173 similar to what you want to do.
175 Another thing this enables is having different variants for the same test
176 case. By default, we run every test for all 3 debug info formats, so once with
177 DWARF from the object files, once with gmodules and finally with a dSYM on
178 macOS or split DWARF (DWO) on Linux. But there are many more things we can test
179 that are orthogonal to the test itself. On GreenDragon we have a matrix bot
180 that runs the test suite under different configurations, with older host
181 compilers and different DWARF versions.
183 As you can imagine, this quickly lead to combinatorial explosion in the number
184 of variants. It's very tempting to add more variants because it's an easy way
185 to increase test coverage. It doesn't scale. It's easy to set up, but increases
186 the runtime of the tests and has a large ongoing cost.
188 The key take away is that the different variants don't obviate the need for
189 focused tests. So relying on it to test say DWARF5 is a really bad idea.
190 Instead you should write tests that check the specific DWARF5 feature, and have
191 the variant as a nice-to-have.
193 In conclusion, you'll want to opt for an API test to test the API itself or
194 when you need the expressivity, either for the test case itself or for the
195 program being debugged. The fact that the API tests work with different
196 variants mean that more general tests should be API tests, so that they can be
197 run against the different variants.
199 Guidelines for API tests
200 ^^^^^^^^^^^^^^^^^^^^^^^^
202 API tests are expected to be fast, reliable and maintainable. To achieve this
203 goal, API tests should conform to the following guidelines in addition to normal
204 good testing practices.
206 **Don't unnecessarily launch the test executable.**
207 Launching a process and running to a breakpoint can often be the most
208 expensive part of a test and should be avoided if possible. A large part
209 of LLDB's functionality is available directly after creating an `SBTarget`
210 of the test executable.
212 The part of the SB API that can be tested with just a target includes
213 everything that represents information about the executable and its
214 debug information (e.g., `SBTarget`, `SBModule`, `SBSymbolContext`,
215 `SBFunction`, `SBInstruction`, `SBCompileUnit`, etc.). For test executables
216 written in languages with a type system that is mostly defined at compile
217 time (e.g., C and C++) there is also usually no process necessary to test
218 the `SBType`-related parts of the API. With those languages it's also
219 possible to test `SBValue` by running expressions with
220 `SBTarget.EvaluateExpression` or the `expect_expr` testing utility.
222 Functionality that always requires a running process is everything that
223 tests the `SBProcess`, `SBThread`, and `SBFrame` classes. The same is true
224 for tests that exercise breakpoints, watchpoints and sanitizers.
225 Languages such as Objective-C that have a dependency on a runtime
226 environment also always require a running process.
228 **Don't unnecessarily include system headers in test sources.**
229 Including external headers slows down the compilation of the test executable
230 and it makes reproducing test failures on other operating systems or
231 configurations harder.
233 **Avoid specifying test-specific compiler flags when including system headers.**
234 If a test requires including a system header (e.g., a test for a libc++
235 formatter includes a libc++ header), try to avoid specifying custom compiler
236 flags if possible. Certain debug information formats such as ``gmodules``
237 use a cache that is shared between all API tests and that contains
238 precompiled system headers. If you add or remove a specific compiler flag
239 in your test (e.g., adding ``-DFOO`` to the ``Makefile`` or ``self.build``
240 arguments), then the test will not use the shared precompiled header cache
241 and expensively recompile all system headers from scratch. If you depend on
242 a specific compiler flag for the test, you can avoid this issue by either
243 removing all system header includes or decorating the test function with
244 ``@no_debug_info_test`` (which will avoid running all debug information
245 variants including ``gmodules``).
247 **Test programs should be kept simple.**
248 Test executables should do the minimum amount of work to bring the process
249 into the state that is required for the test. Simulating a 'real' program
250 that actually tries to do some useful task rarely helps with catching bugs
251 and makes the test much harder to debug and maintain. The test programs
252 should always be deterministic (i.e., do not generate and check against
255 **Identifiers in tests should be simple and descriptive.**
256 Often test programs need to declare functions and classes which require
257 choosing some form of identifier for them. These identifiers should always
258 either be kept simple for small tests (e.g., ``A``, ``B``, ...) or have some
259 descriptive name (e.g., ``ClassWithTailPadding``, ``inlined_func``, ...).
260 Never choose identifiers that are already used anywhere else in LLVM or
261 other programs (e.g., don't name a class ``VirtualFileSystem``, a function
262 ``llvm_unreachable``, or a namespace ``rapidxml``) as this will mislead
263 people ``grep``'ing the LLVM repository for those strings.
265 **Prefer LLDB testing utilities over directly working with the SB API.**
266 The ``lldbutil`` module and the ``TestBase`` class come with a large amount
267 of utility functions that can do common test setup tasks (e.g., starting a
268 test executable and running the process to a breakpoint). Using these
269 functions not only keeps the test shorter and free of duplicated code, but
270 they also follow best test suite practices and usually give much clearer
271 error messages if something goes wrong. The test utilities also contain
272 custom asserts and checks that should be preferably used (e.g.
273 ``self.assertSuccess``).
275 **Prefer calling the SB API over checking command output.**
276 Avoid writing your tests on top of ``self.expect(...)`` calls that check
277 the output of LLDB commands and instead try calling into the SB API. Relying
278 on LLDB commands makes changing (and improving) the output/syntax of
279 commands harder and the resulting tests are often prone to accepting
280 incorrect test results. Especially improved error messages that contain
281 more information might cause these ``self.expect`` calls to unintentionally
282 find the required ``substrs``. For example, the following ``self.expect``
283 check will unexpectedly pass if it's ran as the first expression in a test:
287 self.expect("expr 2 + 2", substrs=["0"])
289 When running the same command in LLDB the reason for the unexpected success
290 is that '0' is found in the name of the implicitly created result variable:
296 ^ The '0' substring is found here.
298 A better way to write the test above would be using LLDB's testing function
299 ``expect_expr`` will only pass if the expression produces a value of 0:
303 self.expect_expr("2 + 2", result_value="0")
305 **Prefer using specific asserts over the generic assertTrue/assertFalse.**.
306 The `self.assertTrue`/`self.assertFalse` functions should always be your
307 last option as they give non-descriptive error messages. The test class has
308 several expressive asserts such as `self.assertIn` that automatically
309 generate an explanation how the received values differ from the expected
310 ones. Check the documentation of Python's `unittest` module to see what
311 asserts are available. If you can't find a specific assert that fits your
312 needs and you fall back to a generic assert, make sure you put useful
313 information into the assert's `msg` argument that helps explain the failure.
317 # Bad. Will print a generic error such as 'False is not True'.
318 self.assertTrue(expected_string in list_of_results)
319 # Good. Will print expected_string and the contents of list_of_results.
320 self.assertIn(expected_string, list_of_results)
322 **Do not use hard-coded line numbers in your test case.**
324 Instead, try to tag the line with some distinguishing pattern, and use the function line_number() defined in lldbtest.py which takes
325 filename and string_to_match as arguments and returns the line number.
327 As an example, take a look at test/API/functionalities/breakpoint/breakpoint_conditions/main.c which has these
332 return c(val); // Find the line number of c's parent call here.
338 return val + 3; // Find the line number of function "c" here.
340 The Python test case TestBreakpointConditions.py uses the comment strings to find the line numbers during setUp(self) and use them
341 later on to verify that the correct breakpoint is being stopped on and that its parent frame also has the correct line number as
342 intended through the breakpoint condition.
344 **Take advantage of the unittest framework's decorator features.**
346 These features can be use to properly mark your test class or method for platform-specific tests, compiler specific, version specific.
348 As an example, take a look at test/API/lang/c/forward/TestForwardDeclaration.py which has these lines:
350 .. code-block:: python
354 @skipIf(compiler=no_match("clang"))
355 @skipIf(compiler_version=["<", "8.0"])
356 @expectedFailureAll(oslist=["windows"])
357 def test_debug_names(self):
358 """Test that we are able to find complete types when using DWARF v5
359 accelerator tables"""
360 self.do_test(dict(CFLAGS_EXTRAS="-gdwarf-5 -gpubnames"))
362 This tells the test harness that unless we are running "linux" and clang version equal & above 8.0, the test should be skipped.
364 **Class-wise cleanup after yourself.**
366 TestBase.tearDownClass(cls) provides a mechanism to invoke the platform-specific cleanup after finishing with a test class. A test
367 class can have more than one test methods, so the tearDownClass(cls) method gets run after all the test methods have been executed by
370 The default cleanup action performed by the packages/Python/lldbsuite/test/lldbtest.py module invokes the "make clean" os command.
372 If this default cleanup is not enough, individual class can provide an extra cleanup hook with a class method named classCleanup ,
373 for example, in test/API/terminal/TestSTTYBeforeAndAfter.py:
375 .. code-block:: python
378 def classCleanup(cls):
379 """Cleanup the test byproducts."""
380 cls.RemoveTempFile("child_send1.txt")
383 The 'child_send1.txt' file gets generated during the test run, so it makes sense to explicitly spell out the action in the same
384 TestSTTYBeforeAndAfter.py file to do the cleanup instead of artificially adding it as part of the default cleanup action which serves to
385 cleanup those intermediate and a.out files.
392 On Windows any invocations of python should be replaced with python_d, the
393 debug interpreter, when running the test suite against a debug version of
398 On NetBSD you must export ``LD_LIBRARY_PATH=$PWD/lib`` in your environment.
399 This is due to lack of the ``$ORIGIN`` linker feature.
401 Running the Full Test Suite
402 ```````````````````````````
404 The easiest way to run the LLDB test suite is to use the ``check-lldb`` build
407 By default, the ``check-lldb`` target builds the test programs with the same
408 compiler that was used to build LLDB. To build the tests with a different
409 compiler, you can set the ``LLDB_TEST_COMPILER`` CMake variable.
411 It is possible to customize the architecture of the test binaries and compiler
412 used by appending ``-A`` and ``-C`` options respectively to the CMake variable
413 ``LLDB_TEST_USER_ARGS``. For example, to test LLDB against 32-bit binaries
414 built with a custom version of clang, do:
418 $ cmake -DLLDB_TEST_USER_ARGS="-A i386 -C /path/to/custom/clang" -G Ninja
421 Note that multiple ``-A`` and ``-C`` flags can be specified to
422 ``LLDB_TEST_USER_ARGS``.
424 Running a Single Test Suite
425 ```````````````````````````
427 Each test suite can be run separately, similar to running the whole test suite
430 * Use ``check-lldb-unit`` to run just the unit tests.
431 * Use ``check-lldb-api`` to run just the SB API tests.
432 * Use ``check-lldb-shell`` to run just the shell tests.
434 You can run specific subdirectories by appending the directory name to the
435 target. For example, to run all the tests in ``ObjectFile``, you can use the
436 target ``check-lldb-shell-objectfile``. However, because the unit tests and API
437 tests don't actually live under ``lldb/test``, this convenience is only
438 available for the shell tests.
440 Running a Single Test
441 `````````````````````
443 The recommended way to run a single test is by invoking the lit driver with a
444 filter. This ensures that the test is run with the same configuration as when
445 run as part of a test suite.
449 $ ./bin/llvm-lit -sv tools/lldb/test --filter <test>
452 Because lit automatically scans a directory for tests, it's also possible to
453 pass a subdirectory to run a specific subset of the tests.
457 $ ./bin/llvm-lit -sv tools/lldb/test/Shell/Commands/CommandScriptImmediateOutput
460 For the SB API tests it is possible to forward arguments to ``dotest.py`` by
461 passing ``--param`` to lit and setting a value for ``dotest-args``.
465 $ ./bin/llvm-lit -sv tools/lldb/test --param dotest-args='-C gcc'
468 Below is an overview of running individual test in the unit and API test suites
469 without going through the lit driver.
471 Running a Specific Test or Set of Tests: API Tests
472 ``````````````````````````````````````````````````
474 In addition to running all the LLDB test suites with the ``check-lldb`` CMake
475 target above, it is possible to run individual LLDB tests. If you have a CMake
476 build you can use the ``lldb-dotest`` binary, which is a wrapper around
477 ``dotest.py`` that passes all the arguments configured by CMake.
479 Alternatively, you can use ``dotest.py`` directly, if you want to run a test
480 one-off with a different configuration.
482 For example, to run the test cases defined in TestInferiorCrashing.py, run:
486 $ ./bin/lldb-dotest -p TestInferiorCrashing.py
491 $ python dotest.py --executable <path-to-lldb> -p TestInferiorCrashing.py ../packages/Python/lldbsuite/test
493 If the test is not specified by name (e.g. if you leave the ``-p`` argument
494 off), all tests in that directory will be executed:
499 $ ./bin/lldb-dotest functionalities/data-formatter
503 $ python dotest.py --executable <path-to-lldb> functionalities/data-formatter
505 Many more options that are available. To see a list of all of them, run:
509 $ python dotest.py -h
512 Running a Specific Test or Set of Tests: Unit Tests
513 ```````````````````````````````````````````````````
515 The unit tests are simple executables, located in the build directory under ``tools/lldb/unittests``.
517 To run them, just run the test binary, for example, to run all the Host tests:
521 $ ./tools/lldb/unittests/Host/HostTests
524 To run a specific test, pass a filter, for example:
528 $ ./tools/lldb/unittests/Host/HostTests --gtest_filter=SocketTest.DomainListenConnectAccept
531 Running the Test Suite Remotely
532 ```````````````````````````````
534 Running the test-suite remotely is similar to the process of running a local
535 test suite, but there are two things to have in mind:
537 1. You must have the lldb-server running on the remote system, ready to accept
538 multiple connections. For more information on how to setup remote debugging
539 see the Remote debugging page.
540 2. You must tell the test-suite how to connect to the remote system. This is
541 achieved using the ``--platform-name``, ``--platform-url`` and
542 ``--platform-working-dir`` parameters to ``dotest.py``. These parameters
543 correspond to the platform select and platform connect LLDB commands. You
544 will usually also need to specify the compiler and architecture for the
547 Currently, running the remote test suite is supported only with ``dotest.py`` (or
548 dosep.py with a single thread), but we expect this issue to be addressed in the
551 Running tests in QEMU System Emulation Environment
552 ``````````````````````````````````````````````````
554 QEMU can be used to test LLDB in an emulation environment in the absence of
555 actual hardware. `QEMU based testing <https://lldb.llvm.org/use/qemu-testing.html>`_
556 page describes how to setup an emulation environment using QEMU helper scripts
557 found under llvm-project/lldb/scripts/lldb-test-qemu. These scripts currently
558 work with Arm or AArch64, but support for other architectures can be added easily.
560 Debugging Test Failures
561 -----------------------
563 On non-Windows platforms, you can use the ``-d`` option to ``dotest.py`` which
564 will cause the script to print out the pid of the test and wait for a while
565 until a debugger is attached. Then run ``lldb -p <pid>`` to attach.
567 To instead debug a test's python source, edit the test and insert
568 ``import pdb; pdb.set_trace()`` at the point you want to start debugging. In
569 addition to pdb's debugging facilities, lldb commands can be executed with the
570 help of a pdb alias. For example ``lldb bt`` and ``lldb v some_var``. Add this
571 line to your ``~/.pdbrc``:
575 alias lldb self.dbg.HandleCommand("%*")
579 Debugging Test Failures on Windows
580 ``````````````````````````````````
582 On Windows, it is strongly recommended to use Python Tools for Visual Studio
583 for debugging test failures. It can seamlessly step between native and managed
584 code, which is very helpful when you need to step through the test itself, and
585 then into the LLDB code that backs the operations the test is performing.
587 A quick guide to getting started with PTVS is as follows:
590 #. Create a Visual Studio Project for the Python code.
591 #. Go to File -> New -> Project -> Python -> From Existing Python Code.
592 #. Choose llvm/tools/lldb as the directory containing the Python code.
593 #. When asked where to save the .pyproj file, choose the folder ``llvm/tools/lldb/pyproj``. This is a special folder that is ignored by the ``.gitignore`` file, since it is not checked in.
594 #. Set test/dotest.py as the startup file
595 #. Make sure there is a Python Environment installed for your distribution. For example, if you installed Python to ``C:\Python35``, PTVS needs to know that this is the interpreter you want to use for running the test suite.
596 #. Go to Tools -> Options -> Python Tools -> Environment Options
597 #. Click Add Environment, and enter Python 3.5 Debug for the name. Fill out the values correctly.
598 #. Configure the project to use this debug interpreter.
599 #. Right click the Project node in Solution Explorer.
600 #. In the General tab, Make sure Python 3.5 Debug is the selected Interpreter.
601 #. In Debug/Search Paths, enter the path to your ninja/lib/site-packages directory.
602 #. In Debug/Environment Variables, enter ``VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\``.
603 #. If you want to enabled mixed mode debugging, check Enable native code debugging (this slows down debugging, so enable it only on an as-needed basis.)
604 #. Set the command line for the test suite to run.
605 #. Right click the project in solution explorer and choose the Debug tab.
606 #. Enter the arguments to dotest.py.
607 #. Example command options:
612 # Path to debug lldb.exe
613 --executable D:/src/llvmbuild/ninja/bin/lldb.exe
614 # Directory to store log files
615 -s D:/src/llvmbuild/ninja/lldb-test-traces
616 -u CXXFLAGS -u CFLAGS
617 # If a test crashes, show JIT debugging dialog.
618 --enable-crash-dialog
619 # Path to release clang.exe
620 -C d:\src\llvmbuild\ninja_release\bin\clang.exe
621 # Path to the particular test you want to debug.
624 D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test
628 --arch=i686 --executable D:/src/llvmbuild/ninja/bin/lldb.exe -s D:/src/llvmbuild/ninja/lldb-test-traces -u CXXFLAGS -u CFLAGS --enable-crash-dialog -C d:\src\llvmbuild\ninja_release\bin\clang.exe -p TestPaths.py D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test --no-multiprocess
630 .. [#] `https://lldb.llvm.org/python_reference/lldb.SBTarget-class.html#BreakpointCreateByName <https://lldb.llvm.org/python_reference/lldb.SBTarget-class.html#BreakpointCreateByName>`_