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.
See
https://discourse.llvm.org/t/rfc-lets-document-and-enforce-a-minimum-python-version-for-lldb/82731
for discussions.
This matches LLVM's requirement to run tests. For LLDB 20 there will be
a CMake warning telling builders that from LLDB 21 this will be a hard
requirement. From LLDB 21, it will be an error to try to build with
anything <= 3.8.
So there are no code changes in this commit. Once the llvm 20 branch is
created we can remove some < 3.8 support code.
As always, if you disable Python support you will not get any new
warnings or errors from this change.
Lua 5.3 and Lua 5.4 are similar enough that we can easily support both
in LLDB. This patch adds support for building LLDB with both and updates
the documentation accordingly.
Looking at #114276, I realized we have a link to Discourse on the
website, but not Discord. I think it would be helpful to have that link
there for real-time community discussion.
Currently all the headings marked as `#` show up
as a top-level entry in the `Developing LLDB`
toctree. This patch marks these as `##` so only
`Adding Programming Language Support` is displayed
in the table of contents.
I've had multiple request for documentation about the JSON symbol file
format that LLDB supports. This patch documents the structure and
fields, shows a handful of examples and explains how to use it in LLDB.
1. This commit adds LLDB_TEST_PLATFORM_URL, LLDB_TEST_SYSROOT,
LLDB_TEST_PLATFORM_WORKING_DIR, LLDB_SHELL_TESTS_DISABLE_REMOTE cmake
flags to pass arguments for cross-compilation and remote running of both Shell&API tests.
2. To run Shell tests remotely, it adds 'platform select' and 'platform connect' commands to %lldb
substitution.
3. 'remote-linux' feature added to lit to disable tests failing with
remote execution.
4. A separate working directory is assigned to each test to avoid
conflicts during parallel test execution.
5. Remote Shell testing is run only when LLDB_TEST_SYSROOT is set for
building test sources. The recommended compiler for that is Clang.
---------
Co-authored-by: Vladimir Vereschaka <vvereschaka@accesssoftek.com>
