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.
Document how to use MCP support in LLDB. I expect this to change
significantly as the feature matures. For now it covers configuring the
server and two example clients.
Some inter-plugin dependencies are okay, others are not. Yet others not,
but we're sort of stuck with them. The idea is to be able to prevent
backsliding while making sure that acceptable dependencies are..
accepted. For context, see
https://github.com/llvm/llvm-project/pull/139170 and the attached
changes to the documentation.
