Including the results of `sizeof`, `sizeof...`, `__datasizeof`,
`__alignof`, `_Alignof`, `alignof`, `_Countof`, `size_t` literals, and
signed `size_t` literals, the results of pointer-pointer subtraction and
checks for standard library functions (and their calls).
The goal is to enable clang and downstream tools such as clangd and
clang-tidy to provide more portable hints and diagnostics.
The previous discussion can be found at #136542.
This PR implements this feature by introducing a new subtype of `Type`
called `PredefinedSugarType`, which was considered appropriate in
discussions. I tried to keep `PredefinedSugarType` simple enough yet not
limited to `size_t` and `ptrdiff_t` so that it can be used for other
purposes. `PredefinedSugarType` wraps a canonical `Type` and provides a
name, conceptually similar to a compiler internal `TypedefType` but
without depending on a `TypedefDecl` or a source file.
Additionally, checks for the `z` and `t` format specifiers in format
strings for `scanf` and `printf` were added. It will precisely match
expressions using `typedef`s or built-in expressions.
The affected tests indicates that it works very well.
Several code require that `SizeType` is canonical, so I kept `SizeType`
to its canonical form.
The failed tests in CI are allowed to fail. See the
[comment](https://github.com/llvm/llvm-project/pull/135386#issuecomment-3049426611)
in another PR #135386.
Deeply nested structs can be noisy, so Apple's LLDB fork sets the
default to `4`:
9c93adbb28/lldb/source/Target/TargetProperties.td (L134-L136)
Thought it would be useful to upstream this. Though happy to pick a
different default or keep it as-is.
Prior, Process Minidump would return
```
Status::FromErrorString("could not parse memory info");
```
For any unsuccessful memory read, with no differentiation between an
error in LLDB and the data simply not being present. This lead to a lot
of user confusion and overall pretty terrible user experience. To fix
this I've refactored the APIs so we can pass an error back in an llvm
expected.
There were also no shell tests for memory read and process Minidump so I
added one.
`(lldb) b` can be used in two different ways:
1. Running `b` without arguments, it lists all existing breakpoints.
2. Running `b` with arguments, it adds breakpoints.
However, the help message doesn't mention the first use case. This patch
adds help message to mention it.
**Without patch**:
```
(lldb) help b
Set a breakpoint using one of several shorthand formats. Expects 'raw' input (see 'help raw-input'.)
Syntax:
_regexp-break <filename>:<linenum>:<colnum>
main.c:12:21 // Break at line 12 and column 21 of main.c
...
```
**With patch**:
```
(lldb) help b
Set a breakpoint using one of several shorthand formats, or list the
existing breakpoints if no arguments are provided. Expects 'raw' input
(see 'help raw-input'.)
Syntax:
_regexp-break <filename>:<linenum>:<colnum>
main.c:12:21 // Break at line 12 and column 21 of main.c
...
_regexp-break
// List the existing breakpoints
```
When dumping variables, LLDB will print a one-time warning about
truncating children (when the children count exceeds the default
`target.max-children-count`). But we only do this for `frame variable`.
So if we use `dwim-print` or `expression`, the output gets truncated but
we don't print a warning. But because we store the fact that we
truncated some output on the `CommandInterpreter`, we fire the warning
next time we use `frame variable`. E.g.,:
```
(lldb) p arr
(int[1000]) {
[0] = -5
[1] = 0
[2] = 0
<-- snipped -->
[253] = 0
[254] = 0
[255] = 0
...
}
(lldb) v someLocal
(int) someLocal = 10
*** Some of the displayed variables have more members than the debugger
will show by default. To show all of them, you can either use the
--show-all-children option to frame variable or raise the limit by
changing the target.max-children-count setting.
```
This patch prints the warning for `dwim-print` and `expression`.
I only added a test for the `target.max-children-count` for now because
it seems the `target.max-children-depth` warning is broken (I can't get
it to fire).
# Lldb-server crash
We have seen stacks like the following in lldb-server core dumps:
```
[
"__GI___pthread_kill at pthread_kill.c:46",
"__GI_raise at raise.c:26",
"__GI_abort at abort.c:100",
"__assert_fail_base at assert.c:92",
"__GI___assert_fail at assert.c:101",
"lldb_private::NativeProcessProtocol::RemoveSoftwareBreakpoint(unsigned long) at /redacted/lldb-server:0"
]
```
# Hypothesis of root cause
In `NativeProcessProtocol::RemoveSoftwareBreakpoint()`
([code](19b2dd9d79/lldb/source/Host/common/NativeProcessProtocol.cpp (L359-L423))),
a `ref_count` is asserted and reduced. If it becomes zero, the code
first go through a series of memory reads and writes to remove the
breakpoint trap opcode and to restore the original process code, then,
if everything goes fine, removes the entry from the map
`m_software_breakpoints` at the end of the function.
However, if any of the validations for the above reads and writes goes
wrong, the code returns an error early, skipping the removal of the
entry. This leaves the entry behind with a `ref_count` of zero.
The next call to `NativeProcessProtocol::RemoveSoftwareBreakpoint()` for
the same breakpoint[*] would violate the assertion about `ref_count > 0`
([here](19b2dd9d79/lldb/source/Host/common/NativeProcessProtocol.cpp (L365))),
which would cause a crash.
[*] We haven't found a *regular* way to repro such a next call in lldb
or lldb-dap. This is because both of them remove the breakpoint from
their internal list when they get any response from the lldb-server (OK
or error). Asking the client to delete the breakpoint a second time
doesn't trigger the client to send the `$z` gdb packet to lldb-server.
We are able to trigger the crash by sending the `$z` packet directly,
see "Manual test" below.
# Fix
Lift the removal of the map entry to be immediately after the decrement
of `ref_count`, before the early returns. This ensures that the asserted
case will never happen. The validation errors can still happen, and
whether they happen or not, the breakpoint has been removed from the
perspective of the lldb-server (same as that of lldb and lldb-dap).
# Manual test & unit test
See PR.
Adds synthetic providers for MSVC's `std::forward_list` and `std::list`.
It refactors `LibCxxList` to be generic over the STL type (currently
libc++ or MSVC STL). The libstdc++ synthetic providers use something
similar in Python
[here](3092b765ba/lldb/examples/synthetic/gnu_libstdcpp.py (L134)).
Eventually, this could be ported to C++ as well.
Towards #24834.
This PR converts the `std::variant` summary from Python to C++.
Split from #148554. MSVC's STL and libstdc++ use the same type name for
`std::variant`, thus they need one "dispatcher" function that checks the
type and calls the appropriate summary. For summaries, both need to be
implemented in C++.
This is mostly a 1:1 translation. The main difference is that in C++,
the summary returns `false` if it can't inspect the object properly
(e.g. a member could not be found). In Python, this wasn't possible.
This adds synthetic child providers for `std::vector<T>` and
`std::vector<bool>` for MSVC's STL.
The structure of a `std::vector<T>` is relatively similar to libc++'s
implementation that uses `__begin` and `__end`.
`std::vector<bool>` is different. It's a `std::vector<unsigned int>`
wrapper instead of `std::vector<uint8_t>`. This makes the calculation
slightly less simple. I put a comment in the `GetChildAtIndex` to make
this clear.
- [NatVis for
`std::vector<T>`](313964b78a/stl/debugger/STL.natvis (L1193-L1205))
- [NatVis for
`std::vector<bool>`](313964b78a/stl/debugger/STL.natvis (L1167-L1179))
Towards #24834.
Some `LangOptions` duplicate their `CodeGenOptions` counterparts. My
understanding is that this was done solely because some infrastructure
(like preprocessor initialization, serialization, module compatibility
checks, etc.) were only possible/convenient for `LangOptions`. This PR
implements the missing support for `CodeGenOptions`, which makes it
possible to remove some duplicate `LangOptions` fields and simplify the
logic. Motivated by https://github.com/llvm/llvm-project/pull/146342.
This commit adds completion support for the plugin commands. It will try
to complete partial namespaces to the full namespace string. If the
completion input is already a full namespace string then it will add all
the matching plugins in that namespace as completions.
This lets the user complete to the namespace first and then tab-complete
to the next level if desired.
```
(lldb) plugin list a<tab>
Available completions:
abi
architecture
(lldb) plugin list ab<tab>
(lldb) plugin list abi<tab>
(lldb) plugin list abi.<tab>
Available completions:
abi.SysV-arm64
abi.ABIMacOSX_arm64
abi.SysV-arm
...
```
…(#144919)"
This was causing a couple of failures on the Ubuntu bots. Reverting
while we wait on a fix for those issues.
This reverts commit 8612926c306c5191a5fb385dd11467728c59e982.
This PR addresses a race condition encountered when using LLDB through
the Python scripting interface.
I'm relatively new to LLDB, so feedback is very welcome, especially if
there's a more appropriate way to address this issue.
### Bug Description
When running a script that repeatedly calls
`debugger.GetListener().WaitForEvent()` in a loop, and at some point
invokes `process.Kill()` from within that loop to terminate the session,
a race condition can occur if `process.Kill()` is called around the same
time a breakpoint is hit.
### Race Condition Details
The issue arises when the following sequence of events happens:
1. The process's **private state** transitions to `stopped` when the
breakpoint is hit.
2. `process.Kill()` calls `Process::Destroy()`, which invokes
`Process::WaitForProcessToStop()`. At this point:
- `private_state = stopped`
- `public_state = running` (the public state has not yet been updated)
3. The **public stop event** is broadcast **before** the hijack listener
is installed.
4. As a result, the stop event is delivered to the **non-hijack
listener**.
5. The interrupt request sent by `Process::StopForDestroyOrDetach()` is
ignored because the process is already stopped (`private_state =
stopped`).
6. No public stop event reaches the hijack listener.
7. `Process::WaitForProcessToStop()` hangs waiting for a public stop
event, but the event is never received.
8. `process.Kill()` times out after 20 seconds
### Fix Summary
This patch modifies `Process::WaitForProcessToStop()` to ensure that any
pending events in the non-hijack listener queue are processed before
checking the hijack listener. This guarantees that any missed public
state change events are handled, preventing the hang.
### Additional Context
A discussion of this issue, including a script to reproduce the bug, can
be found here:
[LLDB hangs when killing process at the same time a breakpoint is
hit](https://discourse.llvm.org/t/lldb-hangs-when-killing-process-at-the-same-time-a-breakpoint-is-hit)
Adds synthetic children for MSVC STL's
[`std::tuple`](313964b78a/stl/inc/tuple).
A `tuple` is a chain of base classes:
```cpp
template <>
class tuple<> {};
template <class _This, class... _Rest>
class tuple<_This, _Rest...> : private tuple<_Rest...> {
_Tuple_val<_This> _Myfirst;
};
```
So the provider walks the base classes to the desired one.
The implementation makes it hard to detect if the empty tuple is from
this STL. Fortunately, libstdc++'s synthetic children provider works for
empty MSVC STL tuples as well.
Towards #24834.
After changes in https://github.com/llvm/llvm-project/pull/145793.
/home/david.spickett/llvm-project/lldb/source/Plugins/Disassembler/LLVMC/DisassemblerLLVMC.cpp:1360:49: error: non-const lvalue reference to type 'uint64_t' (aka 'unsigned long long') cannot bind to a value of unrelated type 'size_t' (aka 'unsigned int')
1360 | status = m_disasm_up->getInstruction(mc_inst, size, data, pc, llvm::nulls());
| ^~~~
/home/david.spickett/llvm-project/llvm/include/llvm/MC/MCDisassembler/MCDisassembler.h:135:64: note: passing argument to parameter 'Size' here
135 | virtual DecodeStatus getInstruction(MCInst &Instr, uint64_t &Size,
| ^
1 error generated.
The type used in the LLVM method we call is uin64_t so use that instead.
It's overkill for what it is, but that's a separate issue if anyone cares.
Also removed the unused form of GetMCInst.
LLDB uses the LLVM disassembler to determine the size of instructions and
to do the actual disassembly. Currently, if the LLVM disassembler can't
disassemble an instruction, LLDB will ignore the instruction size, assume
the instruction size is the minimum size for that device, print no useful
opcode, and print nothing for the instruction.
This patch changes this behavior to separate the instruction size and
"can't disassemble". If the LLVM disassembler knows the size, but can't
dissasemble the instruction, LLDB will use that size. It will print out
the opcode, and will print "<unknown>" for the instruction. This is much
more useful to both a user and a script.
The impetus behind this change is to clean up RISC-V disassembly when
the LLVM disassembler doesn't understand all of the instructions.
RISC-V supports proprietary extensions, where the TD files don't know
about certain instructions, and the disassembler can't disassemble them.
Internal users want to be able to disassemble these instructions.
With llvm-objdump, the solution is to pipe the output of the disassembly
through a filter program. This patch modifies LLDB's disassembly to look
more like llvm-objdump's, and includes an example python script that adds
a command "fdis" that will disassemble, then pipe the output through a
specified filter program. This has been tested with crustfilt, a sample
filter located at https://github.com/quic/crustfilt .
Changes in this PR:
- Decouple "can't disassemble" with "instruction size".
DisassemblerLLVMC::MCDisasmInstance::GetMCInst now returns a bool for
valid disassembly, and has the size as an out paramter.
Use the size even if the disassembly is invalid.
Disassemble if disassemby is valid.
- Always print out the opcode when -b is specified.
Previously it wouldn't print out the opcode if it couldn't disassemble.
- Print out RISC-V opcodes the way llvm-objdump does.
Code for the new Opcode Type eType16_32Tuples by Jason Molenda.
- Print <unknown> for instructions that can't be disassembled, matching
llvm-objdump, instead of printing nothing.
- Update max riscv32 and riscv64 instruction size to 8.
- Add example "fdis" command script.
- Added disassembly byte test for x86 with known and unknown instructions.
- Added disassembly byte test for riscv32 with known and unknown instructions,
with and without filtering.
- Added test from Jason Molenda to RISC-V disassembly unit tests.
This PR adds a summary and synthetic children for `std::unique_ptr` from
MSVC's STL
([NatVis](313964b78a/stl/debugger/STL.natvis (L285-L303))).
As with libc++, the deleter is only shown if it's non-empty.
Tested both the shared_ptr and unique_ptr tests on Windows.
Towards #24834.
This PR is updating the string table offset (DW_AT_str_offsets_base
which is introduced in `DWARF5`) based on the DWARF format, as per the
DWARF specification; For the 32-bit DWARF format, each offset is 4 bytes
long; for the 64-bit DWARF format, each offset is 8 bytes long.
There is currently no way to prevent `${function.name-with-args}` from
using the `plugin.cplusplus.display.function-name-format` setting. Even
if the setting is set to an empty string. As a way to disable formatting
by language plugin, this patch makes it so
`plugin.cplusplus.display.function-name-format` falls back to the old
way of printing `${function.name-with-args}`. Even if we didn't want to
add a fallback, making the setting an empty string shouldn't really
"succeed".
This patch introduces a new struct and helper API in
`DWARFExpressionList` to expose
variable location metadata (base address, end address, and
DWARFExpression pointer) for
a given PC address. It will be used in later patches to annotate
disassembly instructions
with source-level variable locations.
## New struct
```
/// Represents one entry in a DWARFExpressionList, with its range and expr.
struct DWARFExpressionEntry {
lldb::addr_t base; // file‐address start of this location range
lldb::addr_t end; // file‐address end of this range (exclusive)
const DWARFExpression *expr; // the DWARF expression for this range
};
```
## New API
```
/// Retrieve the DWARFExpressionEntry covering a particular instruction.
///
/// \param func_load_addr
/// The load address of the start of the function containing this location list;
/// used to translate between file offsets and load addresses. If this is
/// LLDB_INVALID_ADDRESS, the stored CU base (m_func_file_addr) is used.
///
/// \param load_addr
/// The load address of the *current* PC (i.e., the instruction for which
/// we want its variable‐location entry). We first convert this back into
/// the function’s file‐address space to find the correct DWARF range.
///
/// \returns
/// On success, an entry whose `[base,end)` covers this PC; else an Error.
llvm::Expected<DWARFExpressionEntry>
GetExpressionEntryAtAddress(lldb::addr_t func_load_addr,
lldb::addr_t load_addr) const;
```
## Rationale
LLDB already provides:
```
const DWARFExpression *
GetExpressionAtAddress(lldb::addr_t func_load_addr,
lldb::addr_t load_addr) const;
```
However, this only returns the DWARF expression itself, without the
file‐address start (base) and end (end) of the location range. Those
bounds are crucial for:
1) Detecting range beginnings: render a var = <location> annotation
exactly when a variable’s live‐range starts.
2) Detecting range continuation: optionally display a “|” on subsequent
instructions in the same range.
3) Detecting state changes: know when a variable moves (e.g. from one
register to another), becomes a constant, or goes out of scope.
These primitives form the foundation for the Rich Disassembler feature
proposed for GSoC 25.
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
Co-authored-by: Adrian Prantl <adrian.prantl@gmail.com>
Move `RecordDecl::isInjectedClassName` to
`CXXRecordDecl::isInjectedClassName`. C language doesn't have the term
"injected class name".
Co-authored-by: Matheus Izvekov <mizvekov@gmail.com>
Expose debuggers and target as resources through MCP. This has two
advantages:
1. Enables returning data in a structured way. Although tools can return
structured data with the latest revision of the protocol, we might not
be able to update before the majority of clients has adopted it.
2. Enables the user to specify a resource themselves, rather than
letting the model guess which debugger instance it should use.
This PR exposes a resource for debuggers and targets.
The following URI returns information about a given debugger instance:
```
lldb://debugger/<debugger id>
```
For example:
```
{
uri: "lldb://debugger/0"
mimeType: "application/json"
text: "{"debugger_id":0,"num_targets":2}"
}
```
The following URI returns information about a given target:
```
lldb://debugger/<debugger id>/target/<target id>
```
For example:
```
{
uri: "lldb://debugger/0/target/0"
mimeType: "application/json"
text: "{"arch":"arm64-apple-macosx26.0.0","debugger_id":0,"path":"/Users/jonas/llvm/build-ra/bin/count","target_id":0}"
}
```
This commit introduces a new log channel for the disassembler in LLDB,
allowing for better logging of disassembler related activities. The
`LLDBLOG` enum has been updated to include the `Disassembler` channel,
and the relevant logging in the `DisassemblerLLVMC` plugin has been
modified to utilize this new channel. This is in preparation for adding
additional disassembler implementations.
Key Changes:
- Added `Disassembler` to the `LLDBLog` enum.
- Updated logging in `DisassemblerLLVMC.cpp` to use the new
`Disassembler` log channel.
This is an odd corner case of the use of scripts loaded from dSYM's - a
macOS only feature, which can load OS Plugins that re-present the thread
state of the program we attach to. If we find out about and load the
dSYM scripts when we discover a target in the course of attaching to it,
we can end up running the OS plugin before we've started up the private
state thread. However, the os_plugin in that case will be running before
we broadcast the stop event to the public event listener. So it should
formally use the private state and not the public state for the Python
code environment.
This patch says that if we have not yet started up the private state
thread, then any thread that is servicing events is doing so on behalf
of the private state machinery, and should see the private state, not
the public state.
Most of the patch is getting a test that will actually reproduce the
error. Only the test `test_python_os_plugin_remote` actually reproduced
the error. In `test_python_os_plugin` we actually do start up the
private state thread before handling the event. `test_python_os_plugin`
is there for completeness sake.
I forgot to use the non-synthetic value to check for the `_Ptr` member.
Fixes the test failure from #147575.
---------
Co-authored-by: Michael Buch <michaelbuch12@gmail.com>
This PR adds formatters for `std::shared_ptr` and `std::weak_ptr`. They
are similar to the ones from libc++ and libstdc++.
[Section from MSVC STL
NatVis](313964b78a/stl/debugger/STL.natvis (L512-L578)).
To support debugging with PDB debug info, I had to add an early exit in
`GetDesugaredSmartPointerValue`, because with PDB, LLDB doesn't know
about template types. This isn't an issue here, since the typedef type
is already resolved there, so no casting is needed.
The tests don't check for PDB - maybe this should be changed? I don't
know a good way to do this. PDB has the downside that it resolves
typedefs. Here in particular, the test for `element_type` would need to
be replaced with `User` and `std::string` with
`std::basic_string<char,std::char_traits<char>,std::allocator<char> >`.
Towards #24834.
LLDB breakpoint conditions take an expression that's evaluated using the
language of the code where the breakpoint is located. Users have asked
to have an option to tell it to evaluate the expression in a specific
language.
This is feature is especially helpful for Swift, for example for a
condition based on the value in memory at an offset from a register.
Such a condition is pretty difficult to write in Swift, but easy in C.
This PR adds a new argument (-Y) to specify the language of the
condition expression. We can't reuse the current -L option, since you
might want to break on only Swift symbols, but run a C expression there
as per the example above.
rdar://146119507
This RP changes some Breakpoint-related interfaces to return errors. On
its own these improvements are small, but they encourage better error
handling going forward. There are a bunch of other candidates, but these
were the functions that I touched while working on #146602.
Commands that take an address expression/address through the
OptionArgParser::ToAddress method, which has filtered this
user-specified address through one of the Process Fix methods to clear
non-addressable bits (MTE, PAC, top byte ignore, etc). We don't know
what class of address this is, IMEM or DMEM, but this method is passing
the addresses through Process::FixCodeAddress, and on at least one
target, FixCodeAddress clears low bits which are invalid for
instructions.
Correct this to use FixAnyAddress, which doesn't make alignment
assumptions.
The actual issue found was by people debugging on a 32-bit ARM Cortex-M
part, who tried to do a memory read from an odd address, and lldb
returned results starting at the next lower even address.
rdar://154885727
Working in the Breakpoint library is a minefield if you have your editor
configured to trim trailing whitespace. Remove it and format the
affected lines.
This should improve synchronizing the MainLoopWindows monitor thread
with the main loop state.
This uses the `m_ready` and `m_event` event handles to manage when the
Monitor thread continues and adds new tests to cover additional use
cases.
I believe this should fix#147291 but it is hard to ensure a race
condition is fixed without running the CI on multiple
machines/configurations.
---------
Co-authored-by: Pavel Labath <pavel@labath.sk>
Follow-up to
https://github.com/llvm/llvm-project/pull/147165#pullrequestreview-2992585513
Currently when we explicitly dereference a std::shared_ptr, both the
libstdc++ and libc++ formatters will cast the type of the synthetic
pointer child to whatever the `std::shared_ptr::element_type` is aliased
to. E.g.,
```
(lldb) v p
(std::shared_ptr<int>) p = 10 strong=1 weak=0 {
pointer = 0x000000010016c6a0
}
(lldb) v *p
(int) *p = 10
```
However, when we print (or dereference) `p.pointer`, the type devolves
to something less user-friendly:
```
(lldb) v p.pointer
(std::shared_ptr<int>::element_type *) p.pointer = 0x000000010016c6a0
(lldb) v *p.pointer
(std::shared_ptr<int>::element_type) *p.pointer = 10
```
This patch changes both formatters to store the casted type. Then
`GetChildAtIndex` will consistently use the unwrapped type.
This PR adds type summaries for
`std::{string,wstring,u8string,u16string,u32string}` from the MSVC STL.
See https://github.com/llvm/llvm-project/issues/24834 for the MSVC STL
issue.
The following changes were made:
- `dotest.py` now detects if the MSVC STL is available. It does so by
looking at the target triple, which is an additional argument passed
from Lit. It specifically checks for `windows-msvc` to not match on
`windows-gnu` (i.e. MinGW/Cygwin).
- (The main part): Added support for summarizing `std::(w)string` from
MSVC's STL. Because the type names from the libstdc++ (pre C++ 11)
string types are the same as on MSVC's STL, `CXXCompositeSummaryFormat`
is used with two entries, one for MSVC's STL and one for libstdc++.
With MSVC's STL, `std::u{8,16,32}string` is also handled. These aren't
handled for libstdc++, so I put them in `LoadMsvcStlFormatters`.
This combines the libc++ and libstdc++ test cases. The main difference
was that the libstdcpp tests had some tuple indexing tests that libc++
didn't have.
The libstdc++ formatter didn't support size summaries for std::tuple. So
I added a `ContainerSizeSummaryProvider` for it (like we do for libc++).
Additionally, the synthetic frontend would only apply to non-empty
tuples, so I adjusted the regex to match empty ones too. We do this for
libc++ already.
Split out from https://github.com/llvm/llvm-project/pull/146740
### Summary
Currently `target modules dump separate separate-debug-info`
automatically loads up all DWO files, even if deferred loading is
enabled through debug_names. Then, as expected all DWO files (assuming
there is no error loading it), get marked as "loaded".
This change adds the option `--force-load-all-debug-info` or `-f` for
short to force loading all debug_info up, if it hasn't been loaded yet.
Otherwise, it will change default behavior to not load all debug info so
that the correct DWO files will show up for each modules as "loaded" or
not "loaded", which could be helpful in cases where we want to know
which particular DWO files were loaded.
### Testing
#### Unit Tests
Added additional unit tests
`test_dwos_load_json_with_debug_names_default` and
`test_dwos_load_json_with_debug_names_force_load_all` to test both
default behavior and loading with the new flag
`--force-load-all-debug-info`, and changed expected behavior in
`test_dwos_loaded_symbols_on_demand`.
```
bin/lldb-dotest -p TestDumpDwo ~/llvm-project/lldb/test/API/commands/target/dump-separate-debug-info/dwo
```
#### Manual Testing
Compiled a simple binary w/ `--gsplit-dwarf --gpubnames` and loaded it
up:
```
(lldb) target create "./a.out"
Current executable set to '/home/qxy11/hello-world/a.out' (x86_64).
(lldb) help target modules dump separate-debug-info
List the separate debug info symbol files for one or more target modules.
Syntax: target modules dump separate-debug-info <cmd-options> [<filename> [<filename> [...]]]
Command Options Usage:
target modules dump separate-debug-info [-efj] [<filename> [<filename> [...]]]
-e ( --errors-only )
Filter to show only debug info files with errors.
-f ( --force-load-all-debug-info )
Load all debug info files.
-j ( --json )
Output the details in JSON format.
This command takes options and free-form arguments. If your arguments resemble option specifiers (i.e., they start with a - or --), you must use ' -- ' between the end of the
command options and the beginning of the arguments.
(lldb) target modules dump separate-debug-info --j
[
{
"separate-debug-info-files": [
{ ...
"dwo_name": "main.dwo",
"loaded": false
},
{ ...
"dwo_name": "foo.dwo",
"loaded": false
},
{ ...
"dwo_name": "bar.dwo",
"loaded": false
}
],
}
]
(lldb) b main
Breakpoint 1: where = a.out`main + 15 at main.cc:3:12, address = 0x00000000000011ff
(lldb) target modules dump separate-debug-info --j
[
{
"separate-debug-info-files": [
{ ...
"dwo_name": "main.dwo",
"loaded": true,
"resolved_dwo_path": "/home/qxy11/hello-world/main.dwo"
},
{ ...
"dwo_name": "foo.dwo",
"loaded": false
},
{ ...
"dwo_name": "bar.dwo",
"loaded": false
}
],
}
]
(lldb) b foo
Breakpoint 2: where = a.out`foo(int) + 11 at foo.cc:12:11, address = 0x000000000000121b
(lldb) target modules dump separate-debug-info --j
[
{
"separate-debug-info-files": [
{ ...
"dwo_name": "main.dwo",
"loaded": true,
"resolved_dwo_path": "/home/qxy11/hello-world/main.dwo"
},
{ ...
"dwo_name": "foo.dwo",
"loaded": true,
"resolved_dwo_path": "/home/qxy11/hello-world/foo.dwo"
},
{ ...
"dwo_name": "bar.dwo",
"loaded": false
}
],
}
]
(lldb) b bar
Breakpoint 3: where = a.out`bar(int) + 11 at bar.cc:10:9, address = 0x000000000000126b
(lldb) target modules dump separate-debug-info --j
[
{
"separate-debug-info-files": [
{ ...
"dwo_name": "main.dwo",
"loaded": true,
"resolved_dwo_path": "/home/qxy11/hello-world/main.dwo"
},
{ ...
"dwo_name": "foo.dwo",
"loaded": true,
"resolved_dwo_path": "/home/qxy11/hello-world/foo.dwo"
},
{ ...
"dwo_name": "bar.dwo",
"loaded": true,
"resolved_dwo_path": "/home/qxy11/hello-world/bar.dwo"
}
],
}
]
```
The libc++ test was a subset of the tests in libstdc++. This test moves
the libc++ test into `generic` and somne additional test-cases from
`libstdc++` (specifically the recursive unique_ptr case). It turns out
the libstdc++ formatter supports dereferencing using the "object" or
"obj" names. We could either drop those from the tests or support the
same for libc++. I took the latter approach but don't have strong
opinions on this.
Split out from https://github.com/llvm/llvm-project/pull/146740
This combines the libc++ and libstdc++ test cases. The libstdcpp tests
were a subset of the libc++ test, so this patch moves the libcxx test
into generic and removes the libstdcpp test entirely.
Split out from https://github.com/llvm/llvm-project/pull/146740
This patch adjusts the libcxx and libstdcxx std::shared_ptr formatters
to look the same.
Changes to libcxx:
* Now creates a synthetic child called `pointer` (like we already do for
`std::unique_ptr`)
Changes to libstdcxx:
* When asked to dereference the pointer, cast the type of the result
ValueObject to the element type (which we get from the template argument
to std::shared_ptr).
Before:
```
(std::__shared_ptr<int, __gnu_cxx::_S_atomic>::element_type) *foo = 123
```
After:
```
(int) *foo = 123
```
Tested in https://github.com/llvm/llvm-project/pull/147141
This re-uses the `LibcxxContainerSummaryProvider` for the libstdc++
formatters. There's a couple of containers that aren't making use of it
for libstdc++. This patch will make it easier to review when adding
those in the future.
The only difference is that with libc++ the summary string contains the
derefernced pointer value. With libstdc++ we currently display the
pointer itself, which seems redundant. E.g.,
```
(std::unique_ptr<int>) iup = 0x55555556d2b0 {
pointer = 0x000055555556d2b0
}
(std::unique_ptr<std::basic_string<char> >) sup = 0x55555556d2d0 {
pointer = "foobar"
}
```
This patch moves the logic into a common helper that's shared between
the libc++ and libstdc++ formatters.
After this patch we can combine the libc++ and libstdc++ API tests (see
https://github.com/llvm/llvm-project/pull/146740).
LLDB has the concept of an "SDK root", which expresses where the
system libraries and so which are necessary for debugging can be
found. On POSIX platforms, the SDK root is just the root of the
file system, or /.
We need to implement the appropriate method on HostInfoPosix to
prevent the use of the default implementation for which just returns
an error.
This change is needed to support the Swift REPL but may be useful
for other use cases as well.
