The plan is to move all STL formatter API tests into a single directory.
The `std::deque` test is currently the only test that is duplicated
between the `libcxx` and `generic` directories. This patch moves the
libcxx deque tests into `generic` (moving over any functionality that
wasn't tested in the `generic` tests, mainly formatting
pointers/references to `std::deque`).
The actual `unordered_map` tests live in
`data-formatter-stl/generic/unordered`. The tests here are only testing
`std::unordered_map::iterator`. This patch renames the directory
accordingly. This is in preparation for moving all of the STL tests into
the `generic` directory.
This patch fixes a possible data race between main and event handler
threads. Terminated event can be sent from `Disconnect` function or
event handler. Consequently, there are some possible sequences of
events. We must check events twice, because without getting an exited
event, `exit_status` will be None. But, we don't know the order of
events (for example, we can get terminated event before exited event),
so we check events by filter. It is correct, because terminated event
will be sent only once (guarded by `llvm::call_once`).
This patch moved from
[145010](https://github.com/llvm/llvm-project/pull/145010) and based on
idea from this
[comment](https://github.com/llvm/llvm-project/pull/145010#discussion_r2159637210).
From #143177. This combines the summaries for the pre- and post C++ 11
`std::string` as well as `std::wstring`. In all cases, the data pointer
is reachable through `_M_dataplus._M_p`. It has the correct type (i.e.
`char*`/`wchar_t*`) and it's null terminated, so LLDB knows how to
format it as expected when using `GetSummaryAsCString`.
A decorator to skip or XFAIL a test takes effect when the function
that's passed in returns a reason string. The wrappers around
hw_breakpoints_supported were doing that incorrectly by inverting
(calling `not`) on the result, turning it into a boolean, which means
the test is always skipped.
We had two classes named `PipeTest`: one in `PipeTestUtilities.h` and
one in `PipeTest.cpp`. The latter was unintentionally using the wrong
class (from the header) which didn't initialize the HostInfo subsystem.
This resulted in a crash due to a nullptr dereference (`g_fields`) when
`PipePosix::CreateWithUniqueName` called `HostInfoBase::GetProcessTempDir`.
Letting Editline refresh itself is more robust and ensures that the
current text is redraw if it was accidentally cleared. In that scenario
MoveCursor would only fix up the cursor position.
This patch fixes:
lldb/source/Host/posix/ConnectionFileDescriptorPosix.cpp:279:15:
error: format specifies type 'unsigned long' but the argument has
type 'file_t' (aka 'int') [-Werror,-Wformat]
lldb/source/Host/posix/ConnectionFileDescriptorPosix.cpp:383:15:
error: format specifies type 'unsigned long' but the argument has
type 'file_t' (aka 'int') [-Werror,-Wformat]
This updates MainLoopWindows to support events for reading from a pipe
(both anonymous and named pipes) as well as sockets.
This unifies both handle types using `WSAWaitForMultipleEvents` which
can listen to both sockets and handles for change events.
This should allow us to unify how we handle watching pipes/sockets on
Windows and Posix systems.
We can extend this in the future if we want to support watching other
types, like files or even other events like a process life time.
---------
Co-authored-by: Pavel Labath <pavel@labath.sk>
This patch is part of an effort to remove the
`ResolveSDKPathFromDebugInfo` method, and more specifically the variant
which takes a Module as argument.
See the following PR for a follow up on what to do:
- https://github.com/llvm/llvm-project/pull/144913.
---------
Co-authored-by: Michael Buch <michaelbuch12@gmail.com>
As a preliminary to making DIL the default implementation for
'frame var', ran check-lldb forcing 'frame var' to always use DIL,
and discovered a few failing tests. This fixes most of them. The only
remaining failing test is TestDAP_evaluate.py, which now passes
a test case that the test says should fail (still investigating this).
Changes in this PR:
- Sets correct VariableSP, as well as returning ValueObjectSP (needed
for several watchpoint tests).
- Updates error messages, when looking up members, to match what the
rest of LLDB expects. Also update appropriate DIL tests to expect the
updated error messages.
- Updates DIL parser to look for and accept "(anonymous namespace)::" at
the front of a variable name.
This PR introduces support for the DWARF64 format, enabling handling of
64-bit DWARF sections as defined by the DWARF specification. The update
includes adjustments to header parsing and modification of form values
to accommodate 64-bit offsets and values.
Also Added the testcase to verify the DWARF64 format.
They are left over from our previous attempt at DWARF64. The new attempt
is not using them, and they also don't have equivalents in the llvm
DWARFDataExtractor class.
reading, and one bug in the new RegisterContextUnifiedCore class.
The PR I landed a few days ago to allow Mach-O corefiles to augment
their registers with additional per-thread registers in metadata exposed
a few bugs in the x86_64 corefile reader when running under different CI
environments. It also showed a bug in my RegisterContextUnifiedCore
class where I wasn't properly handling lookups of unknown registers
(e.g. the LLDB_GENERIC_RA when debugging an intel target).
The Mach-O x86_64 corefile support would say that it had fpu & exc
registers available in every corefile, regardless of whether they were
actually present. It would only read the bytes for the first register
flavor in the LC_THREAD, the GPRs, but it read them incorrectly, so
sometimes you got more register context than you'd expect. The LC_THREAD
register context specifies a flavor and the number of uint32_t words;
the ObjectFileMachO method would read that number of uint64_t's,
exceeding the GPR register space, but it was followed by FPU and then
EXC register space so it didn't crash. If you had a corefile with GPR
and EXC register bytes, it would be written into the GPR and then FPU
register areas, with zeroes filling out the rest of the context.
This PR ensures we correctly restore the cursor column after resizing
the statusline. To ensure we have space for the statusline, we have to
emit a newline to move up everything on screen. The newline causes the
cursor to move to the start of the next line, which needs to be undone.
Normally, we would use escape codes to save & restore the cursor
position, but that doesn't work here, as the cursor position may have
(purposely) changed. Instead, we move the cursor up one line using an
escape code, but we weren't restoring the column.
Interestingly, Editline was able to recover from this issue through the
LineInfo struct which contains the buffer and the cursor location, which
allows us to compute the column. This PR addresses the bug by having
Editline "refresh" the cursor position.
Fixes#134064
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.
lldb-server had limited support for single-stepping through the lr/sc
atomic sequence. This patch enhances that support for all possible
atomic sequences.
The previous version contained an incorrect regex pattern in the test,
causing the riscv-specific test to run on other platforms. This reland
fixes the regex (see lldb/test/API/riscv/step/TestSoftwareStep.py)
The "process metadata" LC_NOTE allows for thread IDs to be specified in
a Mach-O corefile. This extends the JSON recognzied in that LC_NOTE to
allow for additional registers to be supplied on a per-thread basis.
The registers included in a Mach-O corefile LC_THREAD load command can
only be one of the register flavors that the kernel (xnu) defines in
<mach/arm/thread_status.h> for arm64 -- the general purpose registers,
floating point registers, exception registers.
JTAG style corefile producers may have access to many additional
registers beyond these that EL0 programs typically use, for instance
TCR_EL1 on AArch64, and people developing low level code need access to
these registers. This patch defines a format for including these
registers for any thread.
The JSON in "process metadata" is a dictionary that must have a
`threads` key. The value is an array of entries, one per LC_THREAD in
the Mach-O corefile. The number of entries must match the LC_THREADs so
they can be correctly associated.
Each thread's dictionary must have two keys, `sets`, and `registers`.
`sets` is an array of register set names. If a register set name matches
one from the LC_THREAD core registers, any registers that are defined
will be added to that register set. e.g. metadata can add a register to
the "General Purpose Registers" set that lldb shows users.
`registers` is an array of dictionaries, one per register. Each register
must have the keys `name`, `value`, `bitsize`, and `set`. It may provide
additional keys like `alt-name`, that
`DynamicRegisterInfo::SetRegisterInfo` recognizes.
This `sets` + `registers` formatting is the same that is used by the
`target.process.python-os-plugin-path` script interface uses, both are
parsed by `DynamicRegisterInfo`. The one addition is that in this
LC_NOTE metadata, each register must also have a `value` field, with the
value provided in big-endian base 10, as usual with JSON.
In RegisterContextUnifiedCore, I combine the register sets & registers
from the LC_THREAD for a specific thread, and the metadata sets &
registers for that thread from the LC_NOTE. Even if no LC_NOTE is
present, this class ingests the LC_THREAD register contexts and
reformats it to its internal stores before returning itself as the
RegisterContex, instead of shortcutting and returning the core's native
RegisterContext. I could have gone either way with that, but in the end
I decided if the code is correct, we should live on it always.
I added a test where we process save-core to create a userland corefile,
then use a utility "add-lcnote" to strip the existing "process metadata"
LC_NOTE that lldb put in it, and adds a new one from a JSON string.
rdar://74358787
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
If a server does not support allocating memory in an inferior process or
when debugging a core file, evaluating an expression in the context of a
value object results in an error:
```
error: <lldb wrapper prefix>:43:1: use of undeclared identifier '$__lldb_class'
43 | $__lldb_class::$__lldb_expr(void *$__lldb_arg)
| ^
```
Such expressions require a live address to be stored in the value
object. However, `EntityResultVariable::Dematerialize()` only sets
`ret->m_live_sp` if JIT is available, even if the address points to the
process memory and no custom allocations were made. Similarly,
`EntityPersistentVariable::Dematerialize()` tries to deallocate memory
based on the same check, resulting in an error if the memory was not
previously allocated in `EntityPersistentVariable::Materialize()`.
As an unintended bonus, the patch also fixes a FIXME case in
`TestCxxChar8_t.py`.
Reapply "[NFC][DebugInfo][DWARF] Create new low-level dwarf library (#…
(#145959)
This reapplies cbf781f0bd, with fixes for
the shared-library build and the unconventional sanitizer-runtime build.
Original Description:
This is the culmination of a series of changes described in [1].
Although somewhat large by line count, it is almost entirely mechanical,
creating a new library in DebugInfo/DWARF/LowLevel. This new library has
very minimal dependencies, allowing it to be used from more places than
the normal DebugInfo/DWARF library--in particular from MC.
1.
https://discourse.llvm.org/t/rfc-debuginfo-dwarf-refactor-into-to-lower-and-higher-level-libraries/86665/2
Add a class property for the version string. This allows you to use
access the version string through `lldb.SBDebugger.version` instead of
having to call `lldb.SBDebugger.GetVersionString()`.
This updates the DIL implementation to handle smart pointers (accessing
field members and dereferencing) in the same way the current 'frame
variable' implementation does. It also adds tests for handling smart
pointers, as well as some additional DIL tests.
.. from the guts of GDBRemoteCommunication to ~top level.
This is motivated by #131519 and by the fact that's impossible to guess
whether the author of a symlink intended it to be a "convenience
shortcut" -- meaning it should be resolved before looking for related
files; or an "implementation detail" -- meaning the related files should
be located near the symlink itself.
This debate is particularly ridiculous when it comes to lldb-server
running in platform mode, because it also functions as a debug server,
so what we really just need to do is to pass /proc/self/exe in a
platform-independent manner.
Moving the location logic higher up achieves that as lldb-platform (on
non-macos) can pass `HostInfo::GetProgramFileSpec`, while liblldb can
use the existing complex logic (which only worked on liblldb anyway as
lldb-platform doesn't have a lldb_private::Platform instance).
Another benefit of this patch is a reduction in dependency from
GDBRemoteCommunication to the rest of liblldb (achieved by avoiding the
Platform dependency).
It was assuming that for any location M.N, N was always less than the
number of breakpoint locations. But if you rebuild the target and rerun
multiple times, when the section backing one of the locations is no
longer valid, we remove the location, but we don't reuse the ID. So you
can have a breakpoint that only has location 1.3. The num_locations
check would say that was an invalid location.
c72c0b298c fixed a race condition in Target::GetExecutableModule. The
patch originally added the lock_guard but I suggested using the locking
ModuleList::Modules() helper instead. That didn't consider that the
fallback would still access the ModuleList without holding the lock.
This patch fixes the remaining issue.
The script used to fix up LLDB's header for use in the macOS framework
contained 2 bugs that this commit addreses:
1. The output contents were appended to the output file multiple times
instead of only being written once.
2. The script was not considering LLDB includes that were *not* from the
SB API.
This commit addresses and fixes both of these bugs and updates the
corresponding test to match.
This is the culmination of a series of changes described in [1].
Although somewhat large by line count, it is almost entirely mechanical,
creating a new library in DebugInfo/DWARF/LowLevel. This new library has
very minimal dependencies, allowing it to be used from more places than
the normal DebugInfo/DWARF library--in particular from MC.
I am happy to put it in another location, or to structure it differently
if that makes sense. Some have suggested in BinaryFormat, but it is not
a great fit there. But if that makes more sense to the reviewers, I can
do that.
Another possibility would be to use pass-through headers to allow
clients who don't care to depend only on DebugInfo/DWARF. This would be
a much less invasive change, and perhaps easier for clients. But also a
system that hides details.
Either way, I'm open.
1.
https://discourse.llvm.org/t/rfc-debuginfo-dwarf-refactor-into-to-lower-and-higher-level-libraries/86665/2
…ess" (#144810)
This relands commit e0933ab5ae. The
original commit was causing the test TestCreateAfterAttach.py to fail on
ARM Ubuntu bots. It's possible that this could've been happening because
the test for wait-attach progress reporting is waiting on a process
named "a.out" which could be too generic as multiple other tests (when
run in parallel on the bots) could also be using processes named
"a.out". This commit changes the wait-attach progress report test to
wait on a unique process name.
Original PR description:
This commit adds a progress report when wait-attaching to a process as
well as a test for this.
Original PR link: https://github.com/llvm/llvm-project/pull/144768
The
[protocol](https://microsoft.github.io/debug-adapter-protocol//specification.html#Types_Source)
expects that `sourceReference` be less than `(2^31)-1`, but we currently
represent memory address as source reference, this can be truncated
either when sending through json or by the client. Instead, generate new
source references based on the memory address.
Make the `ResolveSource` function return an optional source.
### Summary
Currently, if the setting `interpreter.save-transcript` is enabled,
whenever we call "statistics dump", it'll default to reporting a huge
list of transcripts which can be a bit noisy. This is because the
current check `GetIncludeTranscript` returns `!GetSummaryOnly()` by
default if no specific transcript-setting option is given in the
statistics dump command (ie. `statistics dump --transcripts=false` or
`statistics dump --transcripts=true`). Then when
`interpreter.save-transcript` is enabled, this saves a list of
transcripts, and the transcript list ends up getting logged by default.
These changes default the option to log transcripts in the `statistics
dump` command to "false". This can still be enabled via the
`--transcripts` option if users want to see a transcript. Since
`interpreter.save-transcript` is false by default, the main delta is
that if `interpreter.save-transcript` is true and summary mode is false,
we now disable saving the transcript.
This also adds a warning to 'statistics dump --transcript=true' when
interpreter.save-transcript is disabled, which should help users
understand
why transcript data is empty.
### Testing
#### Manual testing
Tested with `settings set interpreter.save-transcript true` enabled at
startup on a toy hello-world program:
```
(lldb) settings set interpreter.save-transcript true
(lldb) target create "/home/qxy11/hello-world/a.out"
Current executable set to '/home/qxy11/hello-world/a.out' (x86_64).
(lldb) statistics dump
{
/* no transcript */
}
(lldb) statistics dump --transcript=true
{
"transcript": [
{
"command": "statistics dump",
"commandArguments": "",
"commandName": "statistics dump",
"durationInSeconds": 0.0019650000000000002,
"error": "",
"output": "{...
},
{
"command": "statistics dump --transcript=true",
"commandArguments": "--transcript=true",
"commandName": "statistics dump",
"timestampInEpochSeconds": 1750720021
}
]
}
```
Without `settings set interpreter.save-transcript true`:
```
(lldb) target create "/home/qxy11/hello-world/a.out"
Current executable set to '/home/qxy11/hello-world/a.out' (x86_64).
(lldb) statistics dump
{
/* no transcript */
}
(lldb) statistics dump --transcript=true
{
/* no transcript */
}
warning: transcript requested but none was saved. Enable with 'settings set interpreter.save-transcript true'
```
#### Unit tests
Changed unit tests to account for new expected default behavior to
`false`, and added a couple new tests around expected behavior with
`--transcript=true`.
```
lldb-dotest -p TestStats ~/llvm-sand/external/llvm-project/lldb/test/API/commands/statistics/basic/
```
Desugar any potential references/typedefs before checking
`isStdTemplate`. Previously, the typename might've been:
```
const std::unordered_map<...> &
```
for references. This patch gets the pointee type before grabbing the
canonical type. `GetNonReferenceType` will unwrap typedefs too, so we
should always end up with a non-reference before we get to
`GetCanonicalType`.
https://github.com/llvm/llvm-project/issues/145847
It's not necessary on posix platforms as of #126935 and it's ignored on
windows as of #138896. For both platforms, we have a better way of
inheriting FDs/HANDLEs.
