This makes use of `version -v` added by #170772,
along with fallback methods for LLDB prior to 22.
1. version --verbose (won't work prior to 22)
2. Scripting to call GetBuildConfiguration (won't work if you don't have
a scripting language
3. readelf/other platform's equivalent utility
readelf is recommended for Linux due to security concerns with ldd.
https://man7.org/linux/man-pages/man1/ldd.1.html
"some versions of ldd may attempt to obtain the
dependency information by attempting to directly
execute the program"
The drawback to that is it doesn't show dependencies of dependencies, so
I've noted that. People can use ldd if they trust the binary, but I've
made it clear how to avoid that and why you should avoid it.
Fixes warning:
index.rst:144: WARNING: toctree contains reference to nonexisting document 'use/python'
There used to be such a page but the URL now redirects
to "script-driven-debugging" which is in the "Python Reference"
section.
This was flagged after the changes in 53674e2da4.
Fixes warning:
formatterbytecode.rst:7: WARNING: 'any' reference target not found: ). To use custom data formatters, developers need to edit the global ``~/.lldbinit`
This reverts commit d20d84fec5.
Fixes#169788, but in a different way.
In which I changed an SBError use so that when the function succeeded,
IsValid on the SBError would be true.
This seemed to make sense but SBError acts differently to other SB
classes in this respect. For something like SBMemoryRegionInfo, if
IsValid() is false, you can't do anything with it.
However for SBError, IsValid() true only means there's some underlying
error object in there. If the SBError represents a success, there's no
need to put anything in there.
You can see this intent from a lot of its methods, many have handling
for IsValid() false.
This is not a bug but a misunderstanding of what IsValid means. Yes it
does function the way I expected for most classes, but it does not for
SBError and though that's not intuitive, it is consistent with how we
describe IsValid in the documentation.
So instead of changing that method's use of SBError I'm documenting this
initially counterintuitive behaviour in the SBError header and on the
website (https://lldb.llvm.org/resources/sbapi.html).
RST uses double backtick for plain text. For single backtick it will try
to resolve it to a reference then fall back to plain text if it doesn't
resolve.
This leads to a lot of warnings like:
formatterbytecode.rst:7: WARNING: 'any' reference target not found:
~/.lldbinit
As seen on the publish-sphinx-docs bot.
Single backticks RST tries to resolve to a reference.
Double means plaintext.
Fixes these warnings:
map.rst:803: WARNING: 'any' reference target not found: target.prefer-dynamic-value
map.rst:814: WARNING: 'any' reference target not found: expr
All these are using H1 for the main heading but H3 for the
rest, Sphinx warns about this:
WARNING: Non-consecutive header level increase; H1 to H3 [myst.header]
RST tries to resolve things in single backticks to a reference,
which is not the intention here. Double backticks indicates
plain text formatting.
Fixes warnings in the docs build:
contributing.rst:92: WARNING: 'any' reference target not found: A1
contributing.rst:92: WARNING: 'any' reference target not found: B1
contributing.rst:92: WARNING: 'any' reference target not found: B2
contributing.rst:92: WARNING: 'any' reference target not found: A2
contributing.rst:95: WARNING: 'any' reference target not found: A1->B1
contributing.rst:95: WARNING: 'any' reference target not found: B2->C2
contributing.rst:95: WARNING: 'any' reference target not found: C3->A3
contributing.rst💯 WARNING: 'any' reference target not found: LLDB_ACCEPTABLE_PLUGIN_DEPENDENCIES
contributing.rst💯 WARNING: 'any' reference target not found: LLDB_TOLERATED_PLUGIN_DEPENDENCIES
This tries to parse the block as that language but in these
cases fails because they aren't purely that language. This
falls back to a permissive mode which is fine, but highlights
the invalid tokens like errors which isn't great.
Instead don't try to highlight these blocks. This fixes 4
warnings seen in the docs build:
lldb/docs/use/tutorials/custom-frame-recognizers.md:43: WARNING: Lexing literal_block <...> as "c++" resulted in an error at token: '#'. Retrying in relaxed mode.
lldb/docs/use/tutorials/script-driven-debugging.md:175: WARNING: Lexing literal_block <...> as "c++" resulted in an error at token: '#'. Retrying in relaxed mode.
lldb/docs/use/tutorials/script-driven-debugging.md:426: WARNING: Lexing literal_block <...> as "c++" resulted in an error at token: '#'. Retrying in relaxed mode.
lldb/docs/use/tutorials/writing-custom-commands.md:416: WARNING: Lexing literal_block <...> as "python3" resulted in an error at token: '$'. Retrying in relaxed mode.
Single backtick tries to make a reference to something
and if that fails, renders as plain text.
These 3 weren't finding a reference and so produced
a warning:
variable.rst:975: WARNING: 'any' reference target not found: max_children
The current description mistakenly specified that an address of a local
value in some address space is returned. When testing this with Wasm
runtimes that already implement this command, it can be observed that
the value itself is returned. The value itself may be an address for
languages that use shadow stack in Wasm linear memory, but the value of
an arbitrary local does not always contain that address.
This is an alternative to
https://github.com/llvm/llvm-project/pull/159500, breaking that PR down
into three separate PRs, to make it easier to review.
This first PR of the three adds the basic framework for doing type
casing to the DIL code, but it does not actually do any casting: In this
PR the DIL parser only recognizes builtin type names, and the DIL
interpreter does not do anything except return the original operand (no
casting). The second and third PRs will add most of the type parsing,
and do the actual type casting, respectively.
The only thing the docs should depend on is on the SWIG wrapper
(lldb.py) which only requires parsing the API headers. It should not
depend on building libLLDB.
The dependency was (I believe accidentally) introduced by 59f4267.
Fixes#123316
Logs just helped someone on Discord debug an issue in a way that would
not have been possible just by stepping the Python script. It was that
LLDB could not find the lldb-server binary.
We do talk about logs elsewhere but I think it's fine to repeat
here since it's a lot of people's first experience with scripting.
This patch updates the instructions explaining how to install the
required tools for building `lldb` on Windows, mostly removing the
duplication and removing references to `GnuWin32` which still has
executables built in 2009 and is no longer functional per their website.
I did this when I converted it but never stated so. Adding a comment
stating so. We'll probably forget at some point but might as well.
Also moved the x packet to the last place, after wasm which was
added to the end recently.
This patch adds the notion of "Facade" locations which can be reported
from a ScriptedResolver instead of the actual underlying breakpoint
location for the breakpoint. Also add a "was_hit" method to the scripted
resolver that allows the breakpoint to say which of these "Facade"
locations was hit, and "get_location_description" to provide a
description for the facade locations.
I apologize in advance for the size of the patch. Almost all of what's
here was necessary to (a) make the feature testable and (b) not break
any of the current behavior.
The motivation for this feature is given in the "Providing Facade
Locations" section that I added to the python-reference.rst so I won't
repeat it here.
rdar://152112327
This adds the ability to recognize (and create ValueObjects for) boolean
literals ("true", "false") to DIL. This is a preliminary step to adding
type casting (and also for the ternary op).
This pages improve the LLDB website documentation readability and
discoverability by breaking down the very long python-reference page
into multiple subpages each explaining a specific topic.
The long term goal is to have tutorials for every scripting extension.
This also converts the pages to markdown, since it's easier to write.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch introduces `ScalarLiteralNode` without any uses by other
nodes yet. It also includes lexing and parsing for integer and floating
point numbers.
Reapplies #152308 with a fix.
This patch introduces `ScalarLiteralNode` without any uses by other
nodes yet. It also includes lexing and parsing for integer and floating
point numbers.
This allows other debugger extensions to leverage the `lldb-dap`
extension's settings and logic (e.g. "Server Mode").
Other debugger extensions can invoke these commands to resolve
configuration, create adapter descriptor, and get the `lldb-dap` process
for state tracking, additional interaction, and telemetry.
VS Code commands added:
* `lldb-dap.resolveDebugConfiguration`
* `lldb-dap.resolveDebugConfigurationWithSubstitutedVariables`
* `lldb-dap.createDebugAdapterDescriptor`
* `lldb-dap.getServerProcess`
This patch adds 2 new attributes to `DemangledNameInfo`: `TemplateRange`
and `NameQualifiersRange`. It also introduces the
`function.name-qualifiers` entity formatter which allows tracking
qualifiers between the name of a function and its arguments/template.
This will be used downstream in Swift but may have applications in C++:
https://github.com/swiftlang/llvm-project/pull/11068.
This PR implements a register context for Wasm, which uses virtual
registers to resolve Wasm local, globals and stack values. The registers
are used to implement support for `DW_OP_WASM_location` in the DWARF
expression evaluator (#151010). This also adds a more comprehensive
test, showing that we can use this to show local variables.
Extend support in LLDB for WebAssembly. This PR adds a new Process
plugin (ProcessWasm) that extends ProcessGDBRemote for WebAssembly
targets. It adds support for WebAssembly's memory model with separate
address spaces, and the ability to fetch the call stack from the
WebAssembly runtime.
I have tested this change with the WebAssembly Micro Runtime (WAMR,
https://github.com/bytecodealliance/wasm-micro-runtime) which implements
a GDB debug stub and supports the qWasmCallStack packet.
```
(lldb) process connect --plugin wasm connect://localhost:4567
Process 1 stopped
* thread #1, name = 'nobody', stop reason = trace
frame #0: 0x40000000000001ad
wasm32_args.wasm`main:
-> 0x40000000000001ad <+3>: global.get 0
0x40000000000001b3 <+9>: i32.const 16
0x40000000000001b5 <+11>: i32.sub
0x40000000000001b6 <+12>: local.set 0
(lldb) b add
Breakpoint 1: where = wasm32_args.wasm`add + 28 at test.c:4:12, address = 0x400000000000019c
(lldb) c
Process 1 resuming
Process 1 stopped
* thread #1, name = 'nobody', stop reason = breakpoint 1.1
frame #0: 0x400000000000019c wasm32_args.wasm`add(a=<unavailable>, b=<unavailable>) at test.c:4:12
1 int
2 add(int a, int b)
3 {
-> 4 return a + b;
5 }
6
7 int
(lldb) bt
* thread #1, name = 'nobody', stop reason = breakpoint 1.1
* frame #0: 0x400000000000019c wasm32_args.wasm`add(a=<unavailable>, b=<unavailable>) at test.c:4:12
frame #1: 0x40000000000001e5 wasm32_args.wasm`main at test.c:12:12
frame #2: 0x40000000000001fe wasm32_args.wasm
```
This PR is based on an unmerged patch from Paolo Severini:
https://reviews.llvm.org/D78801. I intentionally stuck to the
foundations to keep this PR small. I have more PRs in the pipeline to
support the other features/packets.
My motivation for supporting Wasm is to support debugging Swift compiled
to WebAssembly:
https://www.swift.org/documentation/articles/wasm-getting-started.html
The instructions to build LLDB standalone contain a CMake configure step
to build LLVM standalone. This configure step needs to also have the
CMake build type in order to work.
This is not recommended to basically anyone but on occasion it's useful
and could be used for testing with other simulator programs for example
bare metal simulators.
It is not something we do officially support or make any quality
guarantees for.
Adding this is also an excuse to document the limitations and make the
time spent setting up system mode look more worthwhile and might be good
to cite in future discussions about testing in simulation.
