This PR adds synthetic children for std::deque from MSVC's STL.
Similar to libstdc++ and libc++, the elements are in a `T**`, so we need
to "subscript" twice. The [NatVis for
deque](313964b78a/stl/debugger/STL.natvis (L1103-L1112))
uses `_EEN_DS` which contains the block size. We can't access this, but
we can access the [constexpr
`_Block_size`](313964b78a/stl/inc/deque (L641)).
Towards #24834.
This PR adds formatters for `std::map`, `std::set`, `std::multimap`,
`std::multiset` as well as their iterators. It's done in one PR because
the types are essentially the same (a tree) except for their value type.
The iterators are required because of the tests.
`MsvcStlTreeIterSyntheticFrontEnd` is based on the libc++ equivalent. As
opposed to `std::list`, there aren't that many duplicates, so I didn't
create a generic type.
For reference, the tree is implemented in
313964b78a/stl/inc/xtree.
Towards #24834.
Adds synthetic children and a summary provider for `std::atomic` on
MSVC's STL. This currently only supports DWARF because it relies on the
template argument. Once there are PDB tests, this will probably use the
return type of some method like `value()` because template types aren't
available there.
Towards #24834.
Adds a summary and synthetic children for MSVC STL's `std::variant`.
This one is a bit complicated because of DWARF vs PDB differences. I put
the representations in comments. Being able to `GetChildMemberWithName`
a member in an anonymous union would make this a lot simpler
(`std::optional` will have something similar iirc).
Towards #24834.
### Context
Over a year ago, I landed support for 64b Memory ranges in Minidump
(#95312). In this patch we added the Memory64 list stream, which is
effectively a Linked List on disk. The layout is a sixteen byte header
and then however many Memory descriptors.
### The Bug
This is a classic off-by one error, where I added 8 bytes instead of 16
for the header. This caused the first region to start 8 bytes before the
correct RVA, thus shifting all memory reads by 8 bytes. We are correctly
writing all the regions to disk correctly, with no physical corruption
but the RVA is defined wrong, meaning we were incorrectly reading memory
### Why wasn't this caught?
One problem we've had is forcing Minidump to actually use the 64b mode,
it would be a massive waste of resources to have a test that actually
wrote >4.2gb of IO to validate the 64b regions, and so almost all
validation has been manual. As a weakness of manual testing, this issue
is psuedo non-deterministic, as what regions end up in 64b or 32b is
handled greedily and iterated in the order it's laid out in
/proc/pid/maps. We often validated 64b was written correctly by
hexdumping the Minidump itself, which was not corrupted (other than the
BaseRVA)
### Why is this showing up now?
During internal usage, we had a bug report that the Minidump wasn't
displaying values. I was unable to repro the issue, but during my
investigation I saw the variables were in the 64b regions which resulted
in me identifying the bug.
### How do we prevent future regressions?
To prevent regressions, and honestly to save my sanity for figuring out
where 8 bytes magically came from, I've added a new API to
SBSaveCoreOptions.
```SBSaveCoreOptions::GetMemoryRegionsToSave()```
The ability to get the memory regions that we intend to include in the Coredump. I added this so we can compare what we intended to include versus what was actually included. Traditionally we've always had issues comparing regions because Minidump includes `/proc/pid/maps` and it can be difficult to know what memoryregion read failure was a genuine error or just a page that wasn't meant to be included.
We are also leveraging this API to choose the memory regions to be generated, as well as for testing what regions should be bytewise 1:1.
After much debate with @clayborg, I've moved all non-stack memory to the Memory64 List. This list doesn't incur us any meaningful overhead and Greg originally suggested doing this in the original 64b PR. This also means we're exercising the 64b path every single time we save a Minidump, preventing regressions on this feature from slipping through testing in the future.
Snippet produced by [minidump.py](https://github.com/clayborg/scripts)
```
MINIDUMP_MEMORY_LIST:
NumberOfMemoryRanges = 0x00000002
MemoryRanges[0] = [0x00007f61085ff9f0 - 0x00007f6108601000) @ 0x0003f655
MemoryRanges[1] = [0x00007ffe47e50910 - 0x00007ffe47e52000) @ 0x00040c65
MINIDUMP_MEMORY64_LIST:
NumberOfMemoryRanges = 0x000000000000002e
BaseRva = 0x0000000000042669
MemoryRanges[0] = [0x00005584162d8000 - 0x00005584162d9000)
MemoryRanges[1] = [0x00005584162d9000 - 0x00005584162db000)
MemoryRanges[2] = [0x00005584162db000 - 0x00005584162dd000)
MemoryRanges[3] = [0x00005584162dd000 - 0x00005584162ff000)
MemoryRanges[4] = [0x00007f6100000000 - 0x00007f6100021000)
MemoryRanges[5] = [0x00007f6108800000 - 0x00007f6108828000)
MemoryRanges[6] = [0x00007f6108828000 - 0x00007f610899d000)
MemoryRanges[7] = [0x00007f610899d000 - 0x00007f61089f9000)
MemoryRanges[8] = [0x00007f61089f9000 - 0x00007f6108a08000)
MemoryRanges[9] = [0x00007f6108bf5000 - 0x00007f6108bf7000)
```
### Misc
As a part of this fix I had to look at LLDB logs a lot, you'll notice I added `0x` to many of the PRIx64 `LLDB_LOGF`. This is so the user (or I) can directly copy paste the address in the logs instead of adding the hex prefix themselves.
Added some SBSaveCore tests for the new GetMemoryAPI, and Docstrings.
CC: @DavidSpickett, @da-viper @labath because we've been working together on save-core plugins, review it optional and I didn't tag you but figured you'd want to know
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 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.
From #148554 - compile tests with exceptions on Windows
(`-fno-exceptions` was added 11 years ago in
c7826524acda6a9c8816261d5c48b94dc92935ed). The variant test uses `try {}
catch {}` to create variants that are valueless by exception. On other
platforms, exceptions are enabled as well.
I have no clue why compiling with exceptions will optimize out
`a_long_guy` in the changed test (even with `-O0`). Taking the address
of that value will ensure it's kept.
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.
Ran my python script from
https://github.com/llvm/llvm-project/pull/97043 over the repo again and
there was 1 duplicate test-case that has been introduced since I last
did this.
This patch renames that test.
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 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.
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.
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.
There are currently no formatters for libstdcpp
std::unorderd_map::iterator. So I removed those test-cases. We already
test them for libc++ in `libcxx/unordered_map-iterator`. And we test
`std::unordered_map` in `generic/unorderd`. So these test-cases would be
redundant.
Split out from https://github.com/llvm/llvm-project/pull/146740
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 just moves the test from `libcxx` to `generic`. There are currently
no `std::function` formatters for libstdc++ so I didn't add a test-case
for it.
Split out from https://github.com/llvm/llvm-project/pull/146740
This just moves the test from `libcxx` to `generic`. There are currently
no `std::initializer_list` formatters for libstdc++ so I didn't add a
test-case for it.
Split out from https://github.com/llvm/llvm-project/pull/146740
This just moves the test from `libcxx` to `generic`. There are currently
no `std::ranges::ref_view` formatters for libstdc++ so I didn't add a
test-case for it.
Split out from https://github.com/llvm/llvm-project/pull/146740
Now that most STL formatter tests have been moved to `generic`. Do the
same for the MSVC tests (which are currently just for `std::string`).
The `std::string` test was mostly the same (MSVC just had 1 additional
check, which I moved over).
We also only tested `u8string` with MSVC. So i moved those into
`generic` as-is. I kept it separate from the existing std::string tests
since it requires c++20.
The tests are currently failing for libc++ and libstdc++ because MSVC
had a test case which checked that:
```
std::string overwritten_zero("abc");
const_cast<char *>(overwritten_zero.data())[3] = 'd';
```
prints as `"abc"`. But libc++ and libstdc++ print it as `"abcd"` (which
seems like the more correct thing to do?)
This just moves the test from `libcxx` to `generic`. There are currently
no `std::valarray` formatters for libstdc++ so I didn't add a test-case
for it.
Split out from https://github.com/llvm/llvm-project/pull/146740
… directory
This just moves the test from `libcxx` to `generic`. There are currently
no `std::unordered_map::iterator` formatters for libstdc++ so I didn't
add a test-case for it.
Split out from https://github.com/llvm/llvm-project/pull/146740
This just moves the test from `libcxx` to `generic`. There are currently
no `std::span` formatters for libstdc++ so I didn't add a test-case for
it.
Split out from https://github.com/llvm/llvm-project/pull/146740
This just moves the test from `libcxx` to `generic`. There are currently
no `std::string_view` formatters for libstdc++ so I didn't add a
test-case for it.
Split out from https://github.com/llvm/llvm-project/pull/146740
This just moves the test from `libcxx` to `generic`. There are currently
no `std::queue` formatters for libstdc++ so I didn't add a test-case for
it.
Split out from https://github.com/llvm/llvm-project/pull/146740
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 combines the libc++ and libstdc++ test cases. The main difference
was that the libstdcpp tests had additional tests for
references/pointers to std::string. I moved those over.
The libstdc++ formatters don't support `std::u16string`/`std::u32string`
yet, so I extracted those into XFAILed test cases.
There were also two test assertions that failed for libstdc++:
1. libstdc++ doesn't obey the capped/uncapped summary options
2. When a summary isn't available for a std::string, libc++ would print
"Summary Unavailable", whereas libstdc++ just prints "((null))". This
may be better suited for the STL-specific subdirectories, but left it
here for now.
I put those in separate XFAILed test-cases.
Split out from https://github.com/llvm/llvm-project/pull/146740
This combines the libc++ and libstdc++ test cases. The libstdc++ test
had an additional test-case for "reference to typedef". So I added those
to the generic test. The rest of the tests was the same as libc++.
I also moved the test-case for checking invalid variant indexes into a
separate libstdcpp test because it relied on the layout of the libstdc++
type. We should probably rewrite it in the "simulator" style. But for
now I just moved it.
This also removes some redundant checks for libc++ versions and
existence of the `variant` header, which at this point should be
available anywhere these tests are run.
Split out from https://github.com/llvm/llvm-project/pull/146740
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
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
As a pre-requisite to combine the libcxx and libstdcxx string formatter
tests (see https://github.com/llvm/llvm-project/pull/146740) this patch
splits out the libcxx specific parts into a separate test.
These are probably best tested with the libcxx-simulator tests. But for
now I just moved them.
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
The libc++ and libstdc++ tests were pretty much an exact copy of each
other. This test moves the libc++ test into generic removes it from
libstdc++. I moved the `GLIBCXX_DEBUG` case over from libstdcxx. For
some reason the libstdcxx test was skipped, but it passes on my Linux
machine. So I unskipped it for now.
Split out from https://github.com/llvm/llvm-project/pull/146740
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).
This adds SBBreakpoint::SetIsHardware, allowing clients to mark an
existing breakpoint as a hardware breakpoint purely through the API.
This is safe to do after creation, as the hardware/software distinction
doesn't affect how breakpoint locations are selected.
In some cases (e.g. when writing a trap instruction would alter program
behavior), it's important to use hardware breakpoints. Ideally, we’d
extend the various `Create` methods to support this, but given their
number, this patch limits the scope to the post-creation API. As a
workaround, users can also rely on target.require-hardware-breakpoint or
use the `breakpoint set` command.
rdar://153528045
Terminal resizing continues to be a source of statusline bugs, so much
so that some users have started disabling it altogether. Different
operating systems and terminal emulators exhibit subtly different
behaviors, making it nearly impossible to handle resizing reliably
across the board.
This patch sidesteps those issues by clearing the entire screen when the
terminal is resized. This avoids having to account for the previous,
potentially wrapped statusline, the underlying cause of many of the
aforementioned bugs.
The obvious downside is that this clears the on-screen history, but I
believe that’s a reasonable trade-off. Note that this only happens when
resizing the terminal; when launching LLDB, the statusline is drawn
without clearing the screen.
rdar://154778410
