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.
This was removed in https://github.com/llvm/llvm-project/pull/135343 in
favour of making it a format variable, which we do here. This follows
the precedent of the `[opt]` and `[artificial]` markers.
Before:
```
thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.2
* frame #0: 0x000000010000037c a.out`inlined1() at inline.cpp:4:3
frame #1: 0x000000010000037c a.out`regular() at inline.cpp:6:17
frame #2: 0x00000001000003b8 a.out`inlined2() at inline.cpp:7:43
frame #3: 0x00000001000003b4 a.out`main at inline.cpp:10:3
frame #4: 0x0000000186345be4 dyld`start + 7040
```
After (note the `[inlined]` markers):
```
thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.2
* frame #0: 0x000000010000037c a.out`inlined1() at inline.cpp:4:3 [inlined]
frame #1: 0x000000010000037c a.out`regular() at inline.cpp:6:17
frame #2: 0x00000001000003b8 a.out`inlined2() at inline.cpp:7:43 [inlined]
frame #3: 0x00000001000003b4 a.out`main at inline.cpp:10:3
frame #4: 0x0000000186345be4 dyld`start + 7040
```
rdar://152642178
Currently, the type `T`'s summary formatter will be matched for `T`,
`T*`, `T**` and so on. This is unexpected in many data formatters. Such
unhandled cases could cause the data formatter to crash. An example
would be the lldb's built-in data formatter for `std::optional`:
```
$ cat main.cpp
#include <optional>
int main() {
std::optional<int> o_null;
auto po_null = &o_null;
auto ppo_null = &po_null;
auto pppo_null = &ppo_null;
return 0;
}
$ clang++ -g main.cpp && lldb -o "b 8" -o "r" -o "v pppo_null"
[lldb crash]
```
This change adds an options `--pointer-match-depth` to `type summary
add` command to allow users to specify how many layer of pointers can be
dereferenced at most when matching a summary formatter of type `T`, as
Jim suggested
[here](https://github.com/llvm/llvm-project/pull/124048/#issuecomment-2611164133).
By default, this option has value 1 which means summary formatter for
`T` could also be used for `T*` but not `T**` nor beyond. This option is
no-op when `--skip-pointers` is set as well.
I didn't add such option for `type synthetic add`, `type format add`,
`type filter add`, because it useful for those command. Instead, they
all have the pointer match depth of 1. When printing a type `T*`, lldb
never print the children of `T` even if there is a synthetic formatter
registered for `T`.
This PR is a subset of the commits made in
https://github.com/swiftlang/llvm-project/pull/10710.
The most notable change is the addition of `PrefixRange` and
`SuffixRange` which are a catch-all to track anything after or before a
function's demangled name. In the case of Swift, this allows to add
support for name highlighting without having to track the range of the
scope and specifiers of a function (this will come in another PR).
This is still leftover from the days when the libc++ and libstdc++
formatters were both written in python and in separate categories. Since
then we group libstdc++ and libc++ formatters into the same cateogry.
This patch removes references to the obsolete `gnu-libstdc++` category
from the docs (and a test).
See [this
thread](https://github.com/llvm/llvm-project/pull/140761#discussion_r2102386080)
for more context
This patch adds another frame-format variable (currently only
implemented in the CPlusPlus language plugin) that represents the
"suffix" of a function. The name is derived from the `DotSuffix` node of
LLVM's Itanium demangler.
For a function name such as `int foo() (.cold)`, the suffix would be
`(.cold)`.
Despite our attempt (build-docs.sh)
to build the documentation with SVG,
it still uses PNG https://llvm.org/doxygen/classllvm_1_1StringRef.html,
and that renders terribly on any high dpi display.
SVG leads to smasller installation and works fine
on all browser (that has been true for _a while_
https://caniuse.com/svg), so this patch just unconditionally build all
dot graphs as SVG in all subprojects and remove the option.
Add the Data Inspection Language (DIL) implementation pieces for
handling plain local and global variable names.
See https://discourse.llvm.org/t/rfc-data-inspection-language/69893 for
information about DIL.
This change includes the basic AST, Lexer, Parser and Evaluator pieces,
as well as some tests.
By far the most important part of this patch is updating
GettingInvolved.rst to include the invite link, but I've grepped for any
other discord.com links.
I'm no Discord expert, but from my experience (confirmed via @preames
kindly testing as well) the direct channel links provide a confusing
experience if you haven't already found and used an invite link to the
LLVM Discord server. If you're logged into Discord but not a member of
LLVM's sever, the web app opens and then...nothing. No channel opens, no
prompt to join the server or even a hint that you need to find an invite
link (and if you're not used to Discord, you likely don't even know
that's necessary).
This patch addresses the issue by providing the invite link where
Discord is mentioned.
There's a lot of fiddly bits to get right here, so I've added a more
complete example and explained why you might choose one method over
another.
I thought about adding this to the qemu testing page, as that's what we
(Linaro) use this for mostly, but it applies to any remote system
whether hardware or simulator.
The meat of this is how we execute expressions and deal with the
aftermath. For most users this will never be a concern, so it functions
more as a design doc than anything else.
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Skipping-Over-Functions-and-Files.html
We can't emulate all the features of that command but we can skip a
function by name with some extra steps.
As far as I know this only matches function name unlike GDB that can
filter on file and line and so on:
```
target.process.thread.step-avoid-regexp -- A regular expression defining functions step-in won't stop in.
```
It's likely it's got some corner cases that don't work, maybe inlining,
but it doesn't seem worth going into it here.
I don't think we can chain lldb interpreter commands, so I have shown
the steps separately.
I have also mentioned `thread step-in` and its alias `sif`. Which were
new to me too.
This PR adds a proof-of-concept for a bytecode designed to ship and
run LLDB data formatters. More motivation and context can be found in
the formatter-bytecode.rst file and on discourse.
https://discourse.llvm.org/t/a-bytecode-for-lldb-data-formatters/82696
Relanding with a fix for a case-sensitive path.
This PR adds a proof-of-concept for a bytecode designed to ship and
run LLDB data formatters. More motivation and context can be found in
the formatter-bytecode.rst file and on discourse.
https://discourse.llvm.org/t/a-bytecode-for-lldb-data-formatters/82696
Relanding with a fix for a case-sensitive path.
