This patch adds `get_priority()` support to synthetic frame providers to
enable priority-based selection when multiple providers match a thread.
This is the first step toward supporting frame provider chaining for
visualizing coroutines, Swift async tasks, and et al.
Priority ordering follows Unix nice convention where lower numbers
indicate higher priority (0 = highest). Providers without explicit
priority return `std::nullopt`, which maps to UINT32_MAX (lowest
priority), ensuring backward compatibility with existing providers.
The implementation adds `GetPriority()` as a virtual method to
`SyntheticFrameProvider` base class, implements it through the scripting
interface hierarchy (`ScriptedFrameProviderInterface` and
`ScriptedFrameProviderPythonInterface`), and updates
`Thread::GetStackFrameList()` to sort applicable providers by priority
before attempting to load them.
Python frame providers can now specify priority:
```python
@staticmethod
def get_priority():
return 10 # Or return None for default priority.
```
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch is a follow-up to 96c733e to fix a missing space in the
frame.pc format entity. This space was intended to be prepended to the
module format entity scope but if the module is not valid, which is
often the case for python pc-less scripted frames, the space between the
pc and the function name is missing.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
The current behavior will pick the first symbol that contains the
address, this causes LLDB to pick the wrong symbol when looking for
swift reflection metadata on Linux, as in that case it is valid for a
symbol to completely encompass another one.
Instead, this function should prefer the symbol which is an exact, if it
exists. As a bonus, this should also be faster in the vast majority of
the cases, as we probably query symbols by their exact address most of
the time.
rdar://166344740
We had a dedicated `StringLexer` class that pretty much just replicates
the `llvm::StringRef` interface. This patch removes the `StringLexer` in
favour of just using `llvm::StringRef`. Much of the string parsing can
be cleaned up, but I tried to keep the changes a small as possible so
just kept the logic and replaced the APIs calls. The only awkward
side-effect of this is that we have to pass a `llvm::StringRef &`
around.
There were some gaps in the API, so added two helper methods to
consume/pop off characters from the front of the StringRef (maybe those
can be added to `llvm::StringRef` in the future).
The `StringLexer` also had a roll-back mechanism used in two places.
That can be handled by just saving a copy of the `StringRef`.
I've been trying to wrap my head around this code but there's a lot of
action-at-a-distance going on which I'm having trouble following. This
patch cleans up a small part of it.
We were passing the `context`s namespace map as a separate mutable
argument. But nothing in this function requires it to be mutable (and
separate from the owning structure). This patch drops the redundant
argument and passes the shared_ptr by value.
Because PDB doesn't know about templates, we need to get to `T` of
`std::atomic<T>` differently. The type includes the `value_type`
typedef, which is always equal to `T`. The native PDB plugin includes
this since #169248.
Then we can run the `std::atomic` test with (native) PDB.
This patch fixes a deadlock due to a race condition inside the
`PipeEvent` class.
The lldp-dap tests on Windows are very prone to this deadlock (from my
testing almost 1/2 times `TestDAP_Launch.py` fails because of a deadlock
inside `PipeEvent`.
Before this patch, the destructor could try to set `m_ready` right
before `PipeEvent::Monitor` would reset it, causing
`WaitForSingleObject(m_ready, INFINITE);` to deadlock.
This is fixed by ensuring all the `SetEvent` and `ResetEvent` calls
inside the class are behind a mutex.
Furthermore, `CancelIoEx` now passes the same `LPOVERLAPPED` reference
as the one used by the blocking calls in `Monitor`. This ensure we only
cancel the IO tasks which were created by `PipeEvent::Monitor`.
(ignore the first commit, it is the dependency of this PR)
Servers advertise what their maximum packet size is, MultiMemRead needs
to respect that.
Depends on:
* https://github.com/llvm/llvm-project/pull/172020
Typedef/using declarations in structs and classes were not created with
the native PDB plugin. The following would only create `Foo` and
`Foo::Bar`:
```cpp
struct Foo {
struct Bar {};
using Baz = Bar;
using Int = int;
};
```
With this PR, they're created. One complication is that typedefs and
nested types show up identical. The example from above gives:
```
0x1006 | LF_FIELDLIST [size = 40, hash = 0x2E844]
- LF_NESTTYPE [name = `Bar`, parent = 0x1002]
- LF_NESTTYPE [name = `Baz`, parent = 0x1002]
- LF_NESTTYPE [name = `Int`, parent = 0x0074 (int)]
```
To distinguish nested types and typedefs, we check if the parent of a
type is equal to the current one (`parent(0x1002) == 0x1006`) and if the
basename matches the nested type name.
When the command interpreter is asked to not echo commands but still
print errors, a user has no idea what command caused the error.
For example, when I add `bogus` in my `~/.lldbinit`:
```
$ lldb
error: 'bogus' is not a valid command.
```
Things are even more confusing when we have inline diagnostics, which
point to nothing. For example, when I add `settings set target.run-args
-foo` to my `~/.lldbinit`:
```
❯ lldb
˄˜˜˜
╰─ error: unknown or ambiguous option
```
We should still echo the command if the command fails, making it obvious
which command caused the failure and fixing the inline diagnostics.
Fixes#171514
We fall back to `Objective-C++` when running C++ expressions in frames
that don't have debug-info. But we were missing a fallback note for this
situation. We would now print following note on expression error:
```
note: Possibly stopped inside system library, so speculatively enabled Objective-C. Ran expression as 'Objective C++'.
```
The utility expressions in the `InstrumentationRuntime` plugins are just
plain C code, but we run them as `ObjC++`. That meant we were doing
redundant work (like looking up decls in the Objective-C runtime). The
sanitizer tests sporadically time out while looking up function symbols
in the Objective-C runtime. This patch switches the expression language
to `C`.
Didn't find a great way of testing this other than looking at the
expression log.
rdar://165656320
Instead of returning an `Expected<vector<...>>` it now returns an Error,
and receives a vector argument to fill in. This will be useful to
support a change were ParseMultiMemReadPacket will be called multiple
times in a loop with the same vector; without this change, we would have
to concatenate vectors and copy memory around.
This patch improves the way lldb checks if the terminal it's opened in
(if any) supports Unicode or not.
On POSIX systems, we check if `LANG` contains `UTF-8`.
On Windows, we always return `true` since we use the `WriteToConsoleW`
api.
This is a relanding of https://github.com/llvm/llvm-project/pull/168603.
The tests failed because the bots support Unicode but the tests expect
ASCII. To avoid different outputs depending on the environment the tests
are running in, this patch always force ASCII in the tests.
We used to search for constants using the name we parsed. For C++, this
would mean using the demangled struct name (from the unique name). This
name is not always equal to the one used for the struct's name by the
compiler. For example:
```
0x105E | LF_STRUCTURE [size = 120, hash = 0xF38F] ``anonymous namespace'::Anonymous<A::B::C<void> >::D`
unique name: `.?AUD@?$Anonymous@U?$C@X@B@A@@@?A0x8C295248@@`
```
We would use the unique name and get to `(anonymous
namespace)::Anonymous<struct A::B::C<void>>::D`. Then, when finding the
constant in the field list, we'd search for `(anonymous
namespace)::Anonymous<struct A::B::C<void>>::D::StaticMember`. This
wouldn't yield any results, because the constant will use the demangled
name as given by the compiler.
With this PR, we use the struct's name as given in the PDB and append
the member name.
This is a follow up to https://github.com/llvm/llvm-project/pull/152020,
continuing the removal of now-redundant `if(process && target)` checks.
Since this causes a diff in every line of the affected functions, this
commit also uses the opportunity to create some helper functions and
reduce nesting of the affected methods by rewriting all pre-condition
checks as early returns, while remaining strictly NFC.
This has exposed some odd behaviors:
1. `SBFrame::GetVariables` has a variable `num_produced` which is
clearly meant to be incremented on every iteration of the loop but it is
only incremented once, after the loop. So its value is always 0 or
1. The variable now lives in `FetchVariablesUnlessInterrupted`.
2. `SBFrame::GetVariables` has an interruption mechanism for local
variables, but not for "recognized arguments". It's unclear if this is
by design or not, but it is now evident that there is a discrepancy
there.
3. In `SBFrame::EvaluateExpression` we only log some error paths, but
not all of them.
To stick to the strictly NFC nature of this patch, it does not address
any of these issues.
This reverts commit
54a4da9df6.
MSVC supports an extension allowing to delete an array of objects via
pointer whose static type doesn't match its dynamic type. This is done
via generation of special destructors - vector deleting destructors.
MSVC's virtual tables always contain a pointer to the vector deleting
destructor for classes with virtual destructors, so not having this
extension implemented causes clang to generate code that is not
compatible with the code generated by MSVC, because clang always puts a
pointer to a scalar deleting destructor to the vtable. As a bonus the
deletion of an array of polymorphic object will work just like it does
with MSVC - no memory leaks and correct destructors are called.
This patch will cause clang to emit code that is compatible with code
produced by MSVC but not compatible with code produced with clang of
older versions, so the new behavior can be disabled via passing
-fclang-abi-compat=21 (or lower).
Fixes https://github.com/llvm/llvm-project/issues/19772
When you run an expression and the result has a dynamic type that is
different from the expression's static result type, we print the result
variable using the dynamic type, but at present when you use the result
variable in an expression later on, we only give you access to the
static type. For instance:
```
(lldb) expr MakeADerivedReportABase()
(Derived *) $0 = 0x00000001007e93e0
(lldb) expr $0->method_from_derived()
^
error: no member named 'method_from_derived' in 'Base'
(lldb)
```
The static return type of that function is `Base *`, but we printed that
the result was a `Derived *` and then only used the `Base *` part of it
in subsequent expressions. That's not very helpful, and forces you to
guess and then cast the result types to their dynamic type in order to
be able to access the full type you were returned, which is
inconvenient.
This patch makes lldb retain the dynamic type of the result variable
(and ditto for persistent result variables).
It also adds more testing of expression result variables with various
types of dynamic values, to ensure we can access both the ivars and
methods of the type we print the result as.
This PR adds a platform for WebAssembly. Heavily inspired by Pavel's
QemuUser, the platform lets you configure a WebAssembly runtime to run a
Wasm binary.
For example, the following configuration can be used to launch binaries
under the WebAssembly Micro Runtime (WARM):
```
settings set -- platform.plugin.wasm.runtime-args --heap-size=1048576
settings set -- platform.plugin.wasm.port-arg -g=127.0.0.1:
settings set -- platform.plugin.wasm.runtime-path /path/to/iwasm-2.4.0
```
With the settings above, you can now launch a binary directly under
WAMR:
```
❯ lldb simple.wasm
(lldb) target create "/Users/jonas/wasm-micro-runtime/product-mini/platforms/darwin/build/simple.wasm"
Current executable set to '/Users/jonas/wasm-micro-runtime/product-mini/platforms/darwin/build/simple.wasm' (wasm32).
(lldb) b main
Breakpoint 1: 2 locations.
(lldb) r
Process 1 launched: '/Users/jonas/wasm-micro-runtime/product-mini/platforms/darwin/build/simple.wasm' (wasm32)
2 locations added to breakpoint 1
[22:28:05:124 - 16FE27000]: control thread of debug object 0x1005e9020 start
[22:28:05:124 - 16FE27000]: Debug server listening on 127.0.0.1:49170
the module name is /Users/jonas/wasm-micro-runtime/product-mini/platforms/darwin/build/simple.wasm
Process 1 stopped
* thread #1, name = 'nobody', stop reason = breakpoint 1.3
frame #0: 0x40000000000001d3 simple.wasm`main at simple.c:8:7
5 }
6
7 int main() {
-> 8 int i = 1;
9 int j = 2;
10 return add(i, j);
11 }
(lldb)
```
The ObjectFile plugin interface accepts an optional DataBufferSP
argument. If the caller has the contents of the binary, it can provide
this in that DataBufferSP. The ObjectFile subclasses in their
CreateInstance methods will fill in the DataBufferSP with the actual
binary contents if it is not set.
ObjectFile base class creates an ivar DataExtractor from the
DataBufferSP passed in.
My next patch will be a caller that creates a VirtualDataExtractor with
the binary data, and needs to pass that in to the ObjectFile plugin,
instead of the bag-of-bytes DataBufferSP. It builds on the previous
patch changing ObjectFile's ivar from DataExtractor to DataExtractorSP
so I could pass in a subclass in the shared ptr. And it will be using
the VirtualDataExtractor that Jonas added in
https://github.com/llvm/llvm-project/pull/168802
No behavior is changed by the patch; we're simply moving the creation of
the DataExtractor to the caller, instead of a DataBuffer that is
immediately used to set up the ObjectFile DataExtractor. The patch is a
bit complicated because all of the ObjectFile subclasses have to
initialize their DataExtractor to pass in to the base class.
I ran the testsuite on macOS and on AArch64 Ubutnu. (btw David, I ran it
under qemu on my M4 mac with SME-no-SVE again, Ubuntu 25.10, checked
lshw(1) cpu capabilities, and qemu doesn't seem to be virtualizing the
SME, that explains why the testsuite passes)
rdar://148939795
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
The history on this is a bit confusing. The libc++ regexes were adjusted
in https://reviews.llvm.org/D57466, and so did the order in which we
load the formatters. Then https://reviews.llvm.org/D66398 changed the
`std::list` regex, to make sure the libc++ formatters don't match the
`cxx11` libstdc++ [Dual ABI
namespace](https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html).
But we changed the order in which we load the formatters again in
https://github.com/llvm/llvm-project/pull/140727. The intention there
was to load libstdc++ first, because it may have inline namespaces that
would match relaxed the libc++ regexes. So that should technically make
this complicated regex workaround obsolete.
I didn't quite follow the entire thread in D66398 because some of the
links are dead. So it's possible something does rely on this. I'd like
to remove it and see. I *think* this should be resolved now by virtue of
how we load the formatters, but if it does break someone, there ought to
be a better solution (as Pavel hinted at in D66398).
Currently if we are debugging an app that was compiled against an SDK
that we don't know about on the host, then every time we evaluate an
expression we get following spam on the console:
```
error: Error while searching for Xcode SDK: Unrecognized SDK type: <some SDK>
error: Error while searching for Xcode SDK: Unrecognized SDK type: <some SDK>
error: Error while searching for Xcode SDK: Unrecognized SDK type: <some SDK>
error: Error while searching for Xcode SDK: Unrecognized SDK type: <some SDK>
error: Error while searching for Xcode SDK: Unrecognized SDK type: <some SDK>
error: Error while searching for Xcode SDK: Unrecognized SDK type: <some SDK>
error: Error while searching for Xcode SDK: Unrecognized SDK type: <some SDK>
error: Error while searching for Xcode SDK: Unrecognized SDK type: <some SDK>
error: Error while searching for Xcode SDK: Unrecognized SDK type: <some SDK>
error: Error while searching for Xcode SDK: Unrecognized SDK type: <some SDK>
error: Error while searching for Xcode SDK: Unrecognized SDK type: <some SDK>
error: Error while searching for Xcode SDK: Unrecognized SDK type: <some SDK>
error: Error while searching for Xcode SDK: Unrecognized SDK type: <some SDK>
```
It is not a fatal error but the way we spam it pretty much ruins the
debugging experience.
This patch makes it so we only log this error once per debugger session.
Not sure how to best test it since we'd need to build a program with a
particular SDK and then make it unrecognized by LLDB. Confirmed manually
that the error only gets reported once after this patch.
Correct the use_editline check in IOHandlerEditline to prevent a crash
when we have an output and/or error file, but no stream. This fixes a
regression introduced by 58279d1 that results in a crash when calling
el_init with a NULL stream.
The original code was checking the stream: GetOutputFILE and
GetErrorFILE.
```
use_editline = GetInputFILE() && GetOutputFILE() && GetErrorFILE() &&
m_input_sp && m_input_sp->GetIsRealTerminal();
```
The new code is checking the file: `m_output_sp` and `m_error_sp`.
```
use_editline = m_input_sp && m_output_sp && m_error_sp &&
m_input_sp->GetIsRealTerminal();
```
The correct check is:
```
use_editline =
m_input_sp && m_input_sp->GetIsRealTerminal() &&
m_output_sp && m_output_sp->GetUnlockedFile().GetStream() &&
m_error_sp && m_error_sp->GetUnlockedFile().GetStream();
```
We don't need to update the check for the input, because we're handling
the missing stream there correctly in the call to the constructor:
```
m_editline_up = std::make_unique<Editline>(
editline_name, m_input_sp ? m_input_sp->GetStream() : nullptr,
m_output_sp, m_error_sp, m_color);
```
We can't do the same for the output and error because we need to pass
the file, not the stream (to do proper locking).
As I was debugging this I added some more assertions. They're generally
useful so I'm keeping them.
Fixes#170891
Split off from #171489. This only adds the lookup of the active type for
a `std::variant` based on the head type (since PDB doesn't have template
info).
This commit leaves "b" aliased to the old _regexp-break for now. The two
variants are identical except that `_regexp-break` allows you to say:
`(lldb) b <unrecognized_input>
`
which gets translated to:
`break set <unrecognized_input>
`
So switching people to `_regexp-break-add` would be a surprising
behavior change. It would be wrong for `_regexp_break-add` have one
branch that call `break set`, so to avoid surprise, I'll add the command
and let people who are playing with `break add` instead of `break set`
can set the alias to the new one by hand for now.
AppendError ends up trimming this "\n" from the end of the string, then
putting another on on. So there's no reason to keep appending the
newline in CommandObjectMultiword::Execute.
These fallback layouts are essentially guesses. Used when there is
no other way to query register information from the debug server.
Therefore there is a risk that LLDB and the debug server disagree,
which can produce strange effects.
I have added a log message here so we have a clue when triaging
these problems.
Note that it's not wrong to assume a layout in some situations.
It's how some debug servers were built. However if you end up
using the fallback when the server expected you to use XML,
you're likely going to have a bad time.
This reverts commit d20d84fec5945fcc16aa6f63879e1458d4af9ea6.
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).
We follow LLVM's style guide for diagnostics, which instructs to start
the first sentence with a lowercase letter, and finish the last sentence
without a period, if it would end in one otherwise.
LLDB can use the wasm name section to populate its symbol table and get
names for functions. However the index space used in the name section is
the "function index space" which includes imported as well as locally
defined functions.
Remove `CommandReturnObject::AppendRawError` and replace its two uses
with `AppendError`, which correctly prefixes the message with `error:`.
The comment for the method is outdated and the prefixing is clearly
desired in both situations.
Since PDB doesn't have template information, we need to get the element
type from somewhere else. I'm using the type of `_Myval` in a list node,
which holds the element type.
We're considering modifying the ObjC runtime's class_rw_t structure to
remove the firstSubclass and nextSiblingClass fields in some cases. LLDB
is currently reading those but not actually using them. Stop doing that
to avoid issues if they are removed by the runtime.
rdar://166084122
We used to set it to `true` up until recently, see
[here](https://github.com/llvm/llvm-project/pull/170802). That's
incorrect because `SuppressInlineNamespace` is actually an enum. What
probably happened is that `SuppressInlineNamespace` used to be a boolean
but got turned into an enum. But the assignment in LLDB wasn't updated.
But because the bitfield is an `unsigned`, the compiler never
complained.
This meant that ever since `SuppressInlineNamespace` became an enum,
we've been setting it to `SuppressInlineNamespaceMode::Redundant`. Which
means we would only omit the inline namespace when displaying typenames
if Clang deemed it unambiguous. This is probably a rare situtation but
the attached test-case is one such scenario. Here, `target var t1`
followed by `target var t2` would print the inline namespace for `t2`,
because in that context, the type is otherwise ambiguous. But because
LLDB's context is lazily constructed, evaluating `t2` first would omit
the inline namespace, because `t1` isn't in the context yet to make it
ambiguous.
This patch sets the `SuppressInlineNamespace` to
`SuppressInlineNamespaceMode::All`, which is most likely what was
intended in the first place, and also removes the above-mentioned
non-determinism from our typename printing.
lldbutil.run_to_line_breakpoint had usages that set column breakpoints,
so I thought there was coverage of that on the command-line, but
actually all the `run_to` utilities use the SB API's, and there weren't
any tests of setting file line & column breakpoint through
`run_break_set`. So I missed that I had typed the column option `c` -
that's taken by `--command`.
This patch fixes that typo and adds a CLI test for file + line + column.
Add a verbose option to the version command and include the "build
configuration" in the command output. This allows users to quickly
identify if their version of LLDB was built with support for
xml/curl/python/lua etc. This data is already available through the SB
API using SBDebugger::GetBuildConfiguration, but this makes it more
discoverable.
```
(lldb) version -v
lldb version 22.0.0git (git@github.com:llvm/llvm-project.git revision 21a2aac5e5456f9181384406f3b3fcad621a7076)
clang revision 21a2aac5e5456f9181384406f3b3fcad621a7076
llvm revision 21a2aac5e5456f9181384406f3b3fcad621a7076
editline_wchar: yes
lzma: yes
curses: yes
editline: yes
fbsdvmcore: yes
xml: yes
lua: yes
python: yes
targets: [AArch64, AMDGPU, ARM, AVR, BPF, Hexagon, Lanai, LoongArch, Mips, MSP430, NVPTX, PowerPC, RISCV, Sparc, SPIRV, SystemZ, VE, WebAssembly, X86, XCore]
curl: yes
```
Resolves#170727
Inside the LLVM codebase, const vector& should just be ArrayRef, as this
more general API works both with vectors, SmallVectors and
SmallVectorImpl, as well as with single elements.
This commit replaces two uses introduced in
https://github.com/llvm/llvm-project/pull/168797 .
So far, the syntax was `target frame-provider register <cmd-options>
[<run-args>]`. Note the optional `run-args` at the end. They are
completely ignored by the actual command, but the command line parser
still accepts them.
This commit removes them.
This was probably a copy-paste error from `CommandObjectProcessLaunch`
which was probably used as a blue-print for `target frame-provider
register`.
Scripted frames that materialize Python functions or other non-native
code are PC-less by design, meaning they don't have valid program
counter values. Previously, these frames would display invalid addresses
(`0xffffffffffffffff`) in backtrace output.
This patch updates `FormatEntity` to detect and suppress invalid address
display for PC-less frames, adds fallback to frame methods when symbol
context is unavailable, and modifies `StackFrame::GetSymbolContext` to
skip PC-based symbol resolution for invalid addresses.
The changes enable PC-less frames to display cleanly with proper
function names, file paths, and line numbers, and allow for source
display of foreign sources (like Python). Includes comprehensive test
coverage demonstrating frames pointing to Python source files.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
