This diffs implements per-core tracing on lldb-server. It also includes tests that ensure that tracing can be initiated from the client and that the jLLDBGetState ppacket returns the list of trace buffers per core.
This doesn't include any decoder changes.
Finally, this makes some little changes here and there improving the existing code.
A specific piece of code that can't reliably be tested is when tracing
per core fails due to permissions. In this case we add a
troubleshooting message and this is the manual test:
```
/proc/sys/kernel/perf_event_paranoid set to 1
(lldb) process trace start --per-core-tracing error: perf event syscall failed: Permission denied
You might need that /proc/sys/kernel/perf_event_paranoid has a value of 0 or -1.
``
Differential Revision: https://reviews.llvm.org/D124858
I'm refactoring IntelPTThreadTrace into IntelPTSingleBufferTrace so that it can
both single threads or single cores. In this diff I'm basically renaming the
class, moving it to its own file, and removing all the pieces that are not used
along with some basic cleanup.
Differential Revision: https://reviews.llvm.org/D124648
This updates the documentation of the gdb-remote protocol, as well as the help messages, to include the new --per-core-tracing option.
Differential Revision: https://reviews.llvm.org/D124640
In order to open perf events per core, we need to first get the list of
core ids available in the system. So I'm adding a function that does
that by parsing /proc/cpuinfo. That seems to be the simplest and most
portable way to do that.
Besides that, I made a few refactors and renames to reflect better that
the cpu info that we use in lldb-server comes from procfs.
Differential Revision: https://reviews.llvm.org/D124573
This diff introduces a new symbol on-demand which skips
loading a module's debug info unless explicitly asked on
demand. This provides significant performance improvement
for application with dynamic linking mode which has large
number of modules.
The feature can be turned on with:
"settings set symbols.load-on-demand true"
The feature works by creating a new SymbolFileOnDemand class for
each module which wraps the actual SymbolFIle subclass as member
variable. By default, most virtual methods on SymbolFileOnDemand are
skipped so that it looks like there is no debug info for that module.
But once the module's debug info is explicitly requested to
be enabled (in the conditions mentioned below) SymbolFileOnDemand
will allow all methods to pass through and forward to the actual SymbolFile
which would hydrate module's debug info on-demand.
In an internal benchmark, we are seeing more than 95% improvement
for a 3000 modules application.
Currently we are providing several ways to on demand hydrate
a module's debug info:
* Source line breakpoint: matching in supported files
* Stack trace: resolving symbol context for an address
* Symbolic breakpoint: symbol table match guided promotion
* Global variable: symbol table match guided promotion
In all above situations the module's debug info will be on-demand
parsed and indexed.
Some follow-ups for this feature:
* Add a command that allows users to load debug info explicitly while using a
new or existing command when this feature is enabled
* Add settings for "never load any of these executables in Symbols On Demand"
that takes a list of globs
* Add settings for "always load the the debug info for executables in Symbols
On Demand" that takes a list of globs
* Add a new column in "image list" that shows up by default when Symbols On
Demand is enable to show the status for each shlib like "not enabled for
this", "debug info off" and "debug info on" (with a single character to
short string, not the ones I just typed)
Differential Revision: https://reviews.llvm.org/D121631
Update the response schema of the TraceGetState packet and add
Intel PT specific response structure that contains the TSC conversion,
if it exists. The IntelPTCollector loads the TSC conversion and caches
it to prevent unnecessary calls to perf_event_open. Move the TSC conversion
calculation from Perf.h to TraceIntelPTGDBRemotePackets.h to remove
dependency on Linux specific headers.
Differential Revision: https://reviews.llvm.org/D122246
Reviewing some recent fixes to the platform packet implementations
in lldb, I saw the docs were out of sync in a few spots. Updated them.
Differential Revision: https://reviews.llvm.org/D118842
As raised here: https://lists.llvm.org/pipermail/llvm-dev/2021-November/153881.html
Now that VS2022 is on general release, LLVM is expected to build on VS2017, VS2019 and VS2022, which is proving hazardous to maintain due to changes in behaviour including preprocessor and constexpr changes. Plus of the few developers that work with VS, many have already moved to VS2019/22.
This patch proposes to raise the minimum supported version to VS2019 (16.x) - I've made the hard limit 16.0 or later, with the soft limit VS2019 16.7 - older versions of VS2019 are "allowed" (at your own risk) via the LLVM_FORCE_USE_OLD_TOOLCHAIN cmake flag.
Differential Revision: https://reviews.llvm.org/D114639
The existing instructions for lldb on Windows can be more explicit. This adds a few details on how to install various components and the easiest way to get to a working build.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D118425
Update examples and docs to demonstrate using `__lldb_init_module` instead of
the idiom that checks for `lldb.debugger` at the top-level.
```
if __name__ == '__main__':
...
elif lldb.debugger:
...
```
Is replaced with:
```
if __name__ == '__main__':
...
def __lldb_init_module(debugger, internal_dict):
...
```
This change is for two reasons. First, it's generally encouraged not to only
use the convenience singletons (`lldb.{debugger,process,target,etc}`)
interactively from the `script` command. Second, there's a bug where
registering a python class as a command (using `command script add -c ...`),
result in the command not being runnable. Note that registering function-backed
commands does not have this bug.
Differential Revision: https://reviews.llvm.org/D117237
Although we moved to Github Issues. The bug report message refers to
Bugzilla still. This patch tries to update these URLs.
Reviewed By: MaskRay, Quuxplusone, jhenderson, libunwind, libc++
Differential Revision: https://reviews.llvm.org/D116351
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
Walter Erquinigo