This should fix a test failure in TestScriptedFrameProvider.py:
https://lab.llvm.org/buildbot/#/builders/18/builds/23398/steps/6/logs/stdio
This is a happening because on 32bit system, addresses don't have the
leading zeroes. This patch removes them to satisfy the checks.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
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>
Majority of the time users are less interested on the memory address of
a type. It is mostly useful for pointer types (the memory address is
shown).
It makes the view more bloated without adding useful information.
can always fall back to the debug console or watch pane to view the
information if necessary.
This patch refactors the way we check for the windows version in the
`@skipIfWindows` decorator.
The new logic reuses the `expectedCompilerVersion` method logic for the
parsing and comparison of the version.
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>
This test used to work on non-Linux platforms that could run simple ELF
objects in a JIT session. However, there is a risk that this will become
too unstable for CI, so let's limit it to what we actually need.
When using --platform remote-* options, explicitly clear the libcxx
configuration variables instead of just warning and continuing with
potentially set values. This prevents the test suite from attempting to
use custom libcxx paths on remote platforms where they're not
applicable.
Also initialize libcxx variables to None when not specified, ensuring a
clean state regardless of how the arguments are parsed.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
A test failure on green dragon shows the ivars with unexpected values.
This makes the test us an explicit `+new` instead of `+alloc` (which is
missing an `-init` call).
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`.
This new section talks about the ways we try to get register
information, how to find out what LLDB decides to do and how to remedy
that choice if needed.
All the methods have their place, so I've tried to present this in the
order we try them. Roughly speaking, each is less accurate than the
previous one. Most people will want to ensure that they're using the XML
from the debug server.
Target definition scripts are the least documented but also most
advanced topic. I have included them because they are the first thing
LLDB checks, but only briefly, as 99.9% of users won't be using one and
should not bother to write one.
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.
These patches update `compileUnits` and `testGetTargetBreakpoints`
requests, which are not a part of DAP. I combine two commits into one MR
to save maintainers time and because it is mostly NFC.
This NFC patch improves removes documentation references to methods that
have been removed in the PseudoTerminal class and adds some `\see`
references.
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
Since we updated our buildbot setup, these have been failing. Ignore
them until we have time to find the real problem, which is something to
do with failing to backtrace, or missing debug info when we do.
Flag changes reverted as those require the X86 target to be enabled.
Don't have time to test fixes as I need to go to sleep so will revert for now.
Reverts: 423919d31f4b55f22b09cd5066534f7c91e71d4b
Implementation files using the Intel syntax typically explicitly specify it.
Do the same for the few files using AT&T syntax.
This enables building LLVM with `-mllvm -x86-asm-syntax=intel` in one's Clang config files
(i.e. a global preference for Intel syntax).
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.
This reverts commit 13b4eb9452d37106b1143723e658010a9b58d344 since it
doesn't fix the test failure.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
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
This is necessary to get the function name in the test, following
20a6c59d8311d92bd8553b22b82a3874e0016edb.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
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 patch implements a workaround for a VSCode bug that causes it to
send disassemble requests with empty memory reference. You can find more
detailed description
[here](https://github.com/microsoft/vscode/pull/270361). I propose to
allow empty memory reference and return invalid instructions when this
occurs.
Error log example:
```
1759923554.517830610 (stdio) --> {"command":"disassemble","arguments":{"memoryReference":"","offset":0,"instructionOffset":-50,"instructionCount":50,"resolveSymbols":true},"type":"request","seq":3}
1759923554.518007517 (stdio) queued (command=disassemble seq=3)
1759923554.518254757 (stdio) <-- {"body":{"error":{"format":"invalid arguments for request 'disassemble': malformed memory reference at arguments.memoryReference\n{\n \"instructionCount\": 50,\n \"instructionOffset\": -50,\n \"memoryReference\": /* error: malformed memory reference */ \"\",\n \"offset\": 0,\n \"resolveSymbols\": true\n}","id":3,"showUser":true}},"command":"disassemble","request_seq":3,"seq":0,"success":false,"type":"response"}
```
I am not sure that we should add workaround here when bug on VSCode
side, but I think this bug affects our users. WDYT?
