If there is no underlying python file to unwrap, GetFile will
use the file descriptor, if available to create a new python
- file object using `open(fd, mode=..., closefd=False)`
+ file object using ``open(fd, mode=..., closefd=False)``
");
FileSP GetFile();
};
Find variables, register sets, registers, or persistent variables using
the frame as the scope.
- The version that doesn't supply a `use_dynamic` value will use the
+ The version that doesn't supply a ``use_dynamic`` value will use the
target's default.") FindValue;
lldb::SBValue
FindValue (const char *name, ValueType value_type);
Get an SBData wrapping what this SBValue points to.
This method will dereference the current SBValue, if its
- data type is a `T\*` or `T[]`, and extract `item_count` elements
- of type `T` from it, copying their contents in an :py:class:`SBData`.
+ data type is a ``T\*`` or ``T[]``, and extract ``item_count`` elements
+ of type ``T`` from it, copying their contents in an :py:class:`SBData`.
:param item_idx: The index of the first item to retrieve. For an array
this is equivalent to array[item_idx], for a pointer
- to `\*(pointer + item_idx)`. In either case, the measurement
- unit for item_idx is the `sizeof(T)` rather than the byte
+ to ``\*(pointer + item_idx)``. In either case, the measurement
+ unit for item_idx is the ``sizeof(T)`` rather than the byte
:param item_count: How many items should be copied into the output. By default
only one item is copied, but more can be asked for.
:return: The contents of the copied items on success. An empty :py:class:`SBData` otherwise.
^^^^^^^^^^^^^
No matter how a reproducer was captured, they can always be replayed with the
-command line driver. When a reproducer is passed with the `--replay` flag, the
+command line driver. When a reproducer is passed with the ``--replay`` flag, the
driver short-circuits and passes off control to the reproducer infrastructure,
effectively bypassing its normal operation. This works because the driver is
implemented using the SB API and is therefore nothing more than a sequence of
(intentionally) makes no attempt to get that right.
The ``LLDB_REGISTER`` macros are printed to standard out between curly braces.
-You'll have to copy-paste those into the corresponding `RegsiterMethods`
+You'll have to copy-paste those into the corresponding ``RegisterMethods``
function in the implementation file. This function is fully specialized in the
corresponding type.
file, :program:`lldb` will look for an init file in the home directory.
If launched with a `REPL`_ option, it will first look for a REPL configuration
file, specific to the REPL language. The init file should be named as follow:
-`.lldbinit-<language>-repl` (i.e. `.lldbinit-swift-repl`). If this file doesn't
+``.lldbinit-<language>-repl`` (i.e. ``.lldbinit-swift-repl``). If this file doesn't
exist, or :program:`lldb` wasn't launch with `REPL`_, meaning there is neither
-a REPL init file nor an application specific init file, `lldb` will fallback to
+a REPL init file nor an application specific init file, ``lldb`` will fallback to
the global ~/.lldbinit.
Secondly, it will look for an .lldbinit file in the current working directory.
> brew install swig cmake ninja
Note that there's an `incompatibility
-<https://github.com/swig/swig/issues/1321>` between Python version 3.7 and later
+<https://github.com/swig/swig/issues/1321>`_ between Python version 3.7 and later
and swig versions older than 4.0.0 which makes builds of LLDB using debug
versions of python unusable. This primarily affects Windows, as debug builds of
LLDB must use debug python as well.
- **Test infrastructure**: Like LLVM it is important to submit tests with your
patches, but note that LLDB uses a different system for tests. Refer to the
- `test documentation <test.html>`_ for more details and the `lldb/test`
+ `test documentation <test.html>`_ for more details and the ``lldb/test``
folder on disk for examples.
- **Coding Style**: LLDB's code style differs from LLVM's coding style.
wrapper types instead of using a bool to indicate success. Returning
a default value when an error occurred is also discouraged.
-* Assertions. Assertions (from `assert.h`) should be used liberally
+* Assertions. Assertions (from ``assert.h``) should be used liberally
to assert internal consistency. Assertions shall **never** be
used to detect invalid user input, such as malformed DWARF. An
assertion should be placed to assert invariants that the developer
errors cannot reasonably be surfaced to the end user, the error may
be written to a topical log channel.
-* Soft assertions. LLDB provides `lldb_assert()` as a soft
+* Soft assertions. LLDB provides ``lldb_assert()`` as a soft
alternative to cover the middle ground of situations that indicate a
- recoverable bug in LLDB. In a Debug configuration `lldb_assert()`
- behaves like `assert()`. In a Release configuration it will print a
+ recoverable bug in LLDB. In a Debug configuration ``lldb_assert()``
+ behaves like ``assert()``. In a Release configuration it will print a
warning and encourage the user to file a bug report, similar to
LLVM's crash handler, and then return execution. Use these sparingly
and only if error handling is not otherwise feasible. Specifically,
- new code should not be using `lldb_assert()` and existing
+ new code should not be using ``lldb_assert()`` and existing
uses should be replaced by other means of error handling.
* Fatal errors. Aborting LLDB's process using
- `llvm::report_fatal_error()` or `abort()` should be avoided at all
+ ``llvm::report_fatal_error()`` or ``abort()`` should be avoided at all
costs. It's acceptable to use `llvm_unreachable()
<https://llvm.org/doxygen/Support_2ErrorHandling_8h.html>`_ for
actually unreachable code such as the default in an otherwise
projects / platform / upstream / llvm.git / commitdiff