Support three new keys in the qProcessInfo response from the remote
gdb stub to handle the case of attaching to a core running some type
of standalone/firmware code and the stub knows the UUID and load
address-or-slide for the binary. There will be no proper DynamicLoader
plugin in this scenario, but we can try to locate and load the binary
into lldb at the correct offset.
Differential Revision: https://reviews.llvm.org/D116211
rdar://75191077
[NFC] As part of using inclusive language within the llvm project, this patch
renames master plan to controlling plan in lldb.
Reviewed By: jingham
Differential Revision: https://reviews.llvm.org/D113019
It is surprisingly difficult to write a simple python script that
can reliably `import lldb` without failing, or crashing. I'm
currently resorting to convolutions like this:
def find_lldb(may_reexec=False):
if prefix := os.environ.get('LLDB_PYTHON_PREFIX'):
if os.path.realpath(prefix) != os.path.realpath(sys.prefix):
raise Exception("cannot import lldb.\n"
f" sys.prefix should be: {prefix}\n"
f" but it is: {sys.prefix}")
else:
line1, line2 = subprocess.run(
['lldb', '-x', '-b', '-o', 'script print(sys.prefix)'],
encoding='utf8', stdout=subprocess.PIPE,
check=True).stdout.strip().splitlines()
assert line1.strip() == '(lldb) script print(sys.prefix)'
prefix = line2.strip()
os.environ['LLDB_PYTHON_PREFIX'] = prefix
if sys.prefix != prefix:
if not may_reexec:
raise Exception(
"cannot import lldb.\n" +
f" This python, at {sys.prefix}\n"
f" does not math LLDB's python at {prefix}")
os.environ['LLDB_PYTHON_PREFIX'] = prefix
python_exe = os.path.join(prefix, 'bin', 'python3')
os.execl(python_exe, python_exe, *sys.argv)
lldb_path = subprocess.run(['lldb', '-P'],
check=True, stdout=subprocess.PIPE,
encoding='utf8').stdout.strip()
sys.path = [lldb_path] + sys.path
This patch aims to replace all that with:
#!/usr/bin/env lldb-python
import lldb
...
... by adding the following features:
* new command line option: --print-script-interpreter-info. This
prints language-specific information about the script interpreter
in JSON format.
* new tool (unix only): lldb-python which finds python and exec's it.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D112973
[NFC] As part of using inclusive language within the llvm project,
this patch replaces master with main when referring to `.chm` files.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D113299
Jim says:
lldb has a -Q or --source-quietly option, which supposedly does:
--source-quietly Tells the debugger to execute this one-line lldb command before any file has been loaded.
That seems like a weird description, since we don't generally use source for one line entries, but anyway, let's try it:
> $LLDB_LLVM/clean-mono/build/Debug/bin/lldb -Q "script print('I should be quiet')" a.out -O "script print('I should be before')" -o "script print('I should be after')"
(lldb) script print('I should be before')
I should be before
(lldb) target create "script print('I should be quiet')"
error: unable to find executable for 'script print('I should be quiet')'
That was weird. The first real -O gets sourced but not quietly, then the argument to the -Q gets treated as the target.
> $LLDB_LLVM/clean-mono/build/Debug/bin/lldb -Q a.out -O "script print('I should be before')" -o "script print('I should be after')"
(lldb) script print('I should be before')
I should be before
(lldb) target create "a.out"
Current executable set to '/tmp/a.out' (x86_64).
(lldb) script print('I should be after')
I should be after
Well, that's a little better, but the -Q option seems to have done nothing.
---
This fixes the description of --source-quietly, as well as causing it
to actually suppress echoing while executing the initialization
commands.
Reviewed By: jingham
Differential Revision: https://reviews.llvm.org/D112988
The recommonmark package is no longer required since all the documents
have been converted to .rst. Remove the related support code from
docs/conf.py.
Differential Revision: https://reviews.llvm.org/D112612
We had two sets of build<flavour> methods, whose bodies were largely
identical. This makes any kind of modification in their vicinity
repetitive and error-prone.
Replace each set with a single method taking an optional debug_info
parameter.
Differential Revision: https://reviews.llvm.org/D111989
This file contain some old reference to files those are now either renamed or replaced.
Also this .txt file didn't generate to html during the sphnix documentation build so I send its contents to resources/test.rst file.
Signed-off-by: Shivam Gupta <shivam98.tkg@gmail.com>
Reviewed By: teemperor, mgorny, JDevlieghere
Differential Revision: https://reviews.llvm.org/D108812
Upadate some .txt files to .rst for consistency as most
of the documentation is written in reStructuredText format.
Signed-off-by: Shivam Gupta <shivam98.tkg@gmail.com>
Differential Revision: https://reviews.llvm.org/D108807
Follow up on https://reviews.llvm.org/D105741
- Add new test that exhaustively checks the output file's content
- Fix typos in documentation and other minor fixes
Reviewed By: wallace
Original Author: jj10306
Differential Revision: https://reviews.llvm.org/D107674
Add a field to the qMemoryRegionInfo packet where the remote stub
can describe the type of memory -- heap, stack. Keep track of
memory regions that are stack memory in lldb. Add a new "--style
stack" to process save-core to request that only stack memory be
included in the corefile.
Differential Revision: https://reviews.llvm.org/D107625
Some files still contained the old University of Illinois Open Source
Licence header. This patch replaces that with the Apache 2 with LLVM
Exception licence.
Differential Revision: https://reviews.llvm.org/D107528
Use hexadecimal numbers rather than decimal in various vFile packets
in order to fix compatibility with gdbserver. This also changes the few
custom LLDB packets -- while technically they do not have to be changed,
it is easier to use the same syntax consistently across LLDB.
Differential Revision: https://reviews.llvm.org/D107475
Sync the mode constants used to drive vFile:open requests with these
used by GDB and defined for the gdb remote protocol. This makes it
possible to use 'platform file open' after connecting to gdbremote
server (and to some degree to operate on the open file modulo other
incompatibilities).
Differential Revision: https://reviews.llvm.org/D106985
Modify OpenOptions enum to open the future path into synchronizing
vFile:open bits with GDB. Currently, LLDB and GDB use different flag
models effectively making it impossible to match bits. Notably, LLDB
uses two bits to indicate read and write status, and uses union of both
for read/write. GDB uses a value of 0 for read-only, 1 for write-only
and 2 for read/write.
In order to future-proof the code for the GDB variant:
1. Add a distinct eOpenOptionReadWrite constant to be used instead
of (eOpenOptionRead | eOpenOptionWrite) when R/W access is required.
2. Rename eOpenOptionRead and eOpenOptionWrite to eOpenOptionReadOnly
and eOpenOptionWriteOnly respectively, to make it clear that they
do not mean to be combined and require update to all call sites.
3. Use the intersection of all three flags when matching against
the three possible values.
This commit does not change the actual bits used by LLDB.
Differential Revision: https://reviews.llvm.org/D106984
This diff introduces Hierarchical Trace Representation (HTR) and creates the `thread trace export ctf -f <filename> -t <thread_id>` command to export an Intel PT trace's HTR to Chrome Trace Format (CTF) for visualization.
See `lldb/docs/htr.rst` for context/documentation on HTR.
**Overview of Changes**
- Add HTR documentation (see `lldb/docs/htr.rst`)
- Add HTR structures (layer, block, block metadata)
- Implement "Basic Super Block" HTR pass
- Add 'thread trace export ctf' command to export the HTR of an Intel PT
trace to Chrome Trace Format (CTF)
As this diff is the first iteration of HTR and trace visualization, future diffs will build on this work by generalizing the internal design of HTR and implementing new HTR passes that provide better trace summarization/visualization.
See attached video for an example of Intel PT trace visualization:
{F17851042}
Original Author: jj10306
Submitted by: wallace
Reviewed By: wallace, clayborg
Differential Revision: https://reviews.llvm.org/D105741
This diff introduces Hierarchical Trace Representation (HTR) and creates the `thread trace export ctf -f <filename> -t <thread_id>` command to export an Intel PT trace's HTR to Chrome Trace Format (CTF) for visualization.
See `lldb/docs/htr.rst` for context/documentation on HTR.
**Overview of Changes**
- Add HTR documentation (see `lldb/docs/htr.rst`)
- Add HTR structures (layer, block, block metadata)
- Implement "Basic Super Block" HTR pass
- Add 'thread trace export ctf' command to export the HTR of an Intel PT
trace to Chrome Trace Format (CTF)
As this diff is the first iteration of HTR and trace visualization, future diffs will build on this work by generalizing the internal design of HTR and implementing new HTR passes that provide better trace summarization/visualization.
See attached video for an example of Intel PT trace visualization:
{F17851042}
Original Author: jj10306
Submitted by: wallace
Reviewed By: wallace, clayborg
Differential Revision: https://reviews.llvm.org/D105741
Remove the DarwinLog and qStructuredDataPlugins support
from debugserver. The DarwinLog plugin was never debugged
fully and made reliable, and the underlying private APIs
it uses have migrated since 2016 so none of them exist
any longer.
Differential Revision: https://reviews.llvm.org/D106324
rdar://75073283
The current LLDB Python docs are missing documentation for all the special
members such as conversion functions (`__int__`) and other special functions
(`__len__`).
The reason for that is that the `automodapi` plugin we're using to generate the
*.rst files simply doesn't emit them. There doesn't seem to be any config option
to enable those in `automodapi` and it's not even clear why they are filtered. I
assume the leading underscore in their names makes them look like private
methods.
This patch just forcibly adds a few selected special members functions to the
list of functions that sphinx should always document. This will cause sphinx to
warn if a class doesn't have one of those functions but it's better than not
having them documented.
The main motivation here is that since `SBAddress.__int__` is one of the few
functions that is only available in the embedded Python REPL which would be good
to have in the public documentation.
Fixes rdar://64647665
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D105480
References with a single '`' around them are interpreted as references instead
of text with monospaced font since the introduction of the new Python API
generator. This meant that all the single-quoted code in this document that
doesn't reference any Python class was throwing sphinx errors. This just adds
the neede extra ` around this code and fixed up the legitimate typos
(e.g. `SBframe` -> `SBFrame`).
Add a new feature to process save-core on Darwin systems -- for
lldb to create a user process corefile with only the dirty (modified
memory) pages included. All of the binaries that were used in the
corefile are assumed to still exist on the system for the duration
of the use of the corefile. A new --style option to process save-core
is added, so a full corefile can be requested if portability across
systems, or across time, is needed for this corefile.
debugserver can now identify the dirty pages in a memory region
when queried with qMemoryRegionInfo, and the size of vm pages is
given in qHostInfo.
Create a new "all image infos" LC_NOTE for Mach-O which allows us
to describe all of the binaries that were loaded in the process --
load address, UUID, file path, segment load addresses, and optionally
whether code from the binary was executing on any thread. The old
"read dyld_all_image_infos and then the in-memory Mach-O load
commands to get segment load addresses" no longer works when we
only have dirty memory.
rdar://69670807
Differential Revision: https://reviews.llvm.org/D88387
This adds a basic SB API for creating and stopping traces.
Note: This doesn't add any APIs for inspecting individual instructions. That'd be a more complicated change and it might be better to enhande the dump functionality to output the data in binary format. I'll leave that for a later diff.
This also enhances the existing tests so that they test the same flow using both the command interface and the SB API.
I also did some cleanup of legacy code.
Differential Revision: https://reviews.llvm.org/D103500
This patch specifies a few guidelines that our API tests should follow.
The motivations for this are twofold:
1. API tests have unexpected pitfalls that especially new contributors run into
when writing tests. To prevent the frustration of letting people figure those
pitfalls out by trial-and-error, let's just document them briefly in one place.
2. It prevents some arguing about what is the right way to write tests. I really
like to have fast and reliable API test suite, but I also don't want to be the
bogeyman that has to insist in every review that the test should be rewritten to
not launch a process for no good reason. It's much easier to just point to a
policy document.
I omitted some guidelines that I think could be controversial (e.g., the whole
"should assert message describe failure or success").
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D101153
Introduce three new stop reasons for fork, vfork and vforkdone events.
This includes server support for serializing fork/vfork events into
gdb-remote protocol. The stop infos for the two base events take a pair
of PID and TID for the newly forked process.
Differential Revision: https://reviews.llvm.org/D100196
When looking up user specified formatters qualifiers are removed from types before matching,
I have added a clarifying example to the document and added an example to a relevant test to demonstrate this behavior.
Differential Revision: https://reviews.llvm.org/D99827
Debugging tests sometimes involves debugging the Python source. This adds a paragraph to
the "Debugging Test Failures" section about using `pdb`, and also describes how to run
lldb commands from pdb.
Differential Revision: https://reviews.llvm.org/D99744
Remove the remaining references to LLDB_CAPTURE_REPRODUCER. I removed
the functionality in an earlier commit but forgot that there was a
corresponding test and logic to unset it in our test suite.
This implements the interactive trace start and stop methods.
This diff ended up being much larger than I anticipated because, by doing it, I found that I had implemented in the beginning many things in a non optimal way. In any case, the code is much better now.
There's a lot of boilerplate code due to the gdb-remote protocol, but the main changes are:
- New tracing packets: jLLDBTraceStop, jLLDBTraceStart, jLLDBTraceGetBinaryData. The gdb-remote packet definitions are quite comprehensive.
- Implementation of the "process trace start|stop" and "thread trace start|stop" commands.
- Implementaiton of an API in Trace.h to interact with live traces.
- Created an IntelPTDecoder for live threads, that use the debugger's stop id as checkpoint for its internal cache.
- Added a functionality to stop the process in case "process tracing" is enabled and a new thread can't traced.
- Added tests
I have some ideas to unify the code paths for post mortem and live threads, but I'll do that in another diff.
Differential Revision: https://reviews.llvm.org/D91679
In D94489 we changed the way we build the docs and now have some additional
dependencies to generate the Python API docs. As the same sphinx project is
generating the man pages for LLDB it should have in theory the same setup code
that sets up the mocked LLDB module.
However, as we don't have that setup code the man page generation just fails as
there is no mocked LLDB module and the Python API generation errors out.
The man page anyway doesn't cover the Python API so I don't think there is any
point of going through the whole process (and requiring the sphinx plugins) just
to generate the (eventually unused) Python docs.
This patch just skips the relevant Python API generation when we are building
the man page.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D98441
Add a column to the table of convenience variables with the equivalent
API to get to the current debugger, target, process, etc.
We often get asked to make convenience variables available outside of
the interactive interpreter. After explaining why that's not possible, a
common complaint is that it's hard to find out how to get to these
variables in a non-interactive context, for example how to get to the
current frame when given a thread. This patch aims to alleviate that by
including the APIs to navigate between these instances in the table.
Differential revision: https://reviews.llvm.org/D97778
This patch changes the short option used in `CommandOptionsProcessLaunch`
for the `-v|--environment` command option to `-E|--environment`.
The reason for that is, that it collides with the `-v|--structured-data-value`
command option generated by `OptionGroupPythonClassWithDict` that
I'm using in an upcoming patch for the `process launch` command.
The long option `--environment` remains the same.
Differential Review: https://reviews.llvm.org/D95100
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Allow users to use a non-system version of perl, python and awk, which is useful
in certain package managers.
Reviewed By: JDevlieghere, MaskRay
Differential Revision: https://reviews.llvm.org/D95119
Jason Molenda