The current implementation of
CPlusPlusLanguage::SymbolNameFitsToLanguage will return true if the
symbol is mangled for any language that lldb knows about.
This way we make sure that the logic to reconstruct demangled names in
the tests is the same as the logic when reconstructing the actual
frame-format variable.
`DemangledNameInfo::SuffixRange` is currently the only one which we
can't test in the same way until we set it from inside the
`TrackingOutputBuffer`. I added TODOs to track this.
This patch adds 2 new attributes to `DemangledNameInfo`: `TemplateRange`
and `NameQualifiersRange`. It also introduces the
`function.name-qualifiers` entity formatter which allows tracking
qualifiers between the name of a function and its arguments/template.
This will be used downstream in Swift but may have applications in C++:
https://github.com/swiftlang/llvm-project/pull/11068.
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.
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.
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.
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 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 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
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.
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`.
Upgrade the callees of `HandleFrameFormatVariable`
(`GetDemangledTemplateArguments`, etc), to return a `llvm::Expected`
instead of an `std::optional`.
This patch also bundles the logic of validating the demangled name and
information into a single reusable function to reduce code duplication.
This fixes a data race between the main thread and the default event
handler thread. The statusline format option value was protected by a
mutex, but it was returned as a pointer, allowing one thread to access
it while another was modifying it.
Avoid the data race by returning format values by value instead of by
pointer.
This PR is a subset of the commits made in
https://github.com/swiftlang/llvm-project/pull/10710.
The most notable change is the addition of `PrefixRange` and
`SuffixRange` which are a catch-all to track anything after or before a
function's demangled name. In the case of Swift, this allows to add
support for name highlighting without having to track the range of the
scope and specifiers of a function (this will come in another PR).
If libstdc++ is compiled with `_GLIBCXX_DEBUG` flag it puts the containers in the namespace `std::__debug`. this causes the summary and synthetic formatters not to match the types. The formatters is updated to optionally match the `__debug::`.
The formatters now clashed with the libc++ containers namespace regex which uses `std::__1` namespace
The libc++ formatter is loaded first, then the libstdc++ since the priority of the formatters in lldb is the last one added.
Fixes#60841
This patch adds another frame-format variable (currently only
implemented in the CPlusPlus language plugin) that represents the
"suffix" of a function. The name is derived from the `DotSuffix` node of
LLVM's Itanium demangler.
For a function name such as `int foo() (.cold)`, the suffix would be
`(.cold)`.
Reverts llvm/llvm-project#137408
This change broke `lldb/test/Shell/Unwind/split-machine-functions.test`.
The test binary has a symbol named `_Z3foov.cold` and the test expects
the backtrace to print the name of the cold part of the function like
this:
```
# SPLIT: frame #1: {{.*}}`foo() (.cold) +
```
but now it gets
```
frame #1: 0x000055555555514f split-machine-functions.test.tmp`foo() + 12
```
This patch makes the frame-format variables introduced in
https://github.com/llvm/llvm-project/pull/131836 also work when no
debug-info is available. Previously, we assumed `sc.function` was
available, but without debug-info we might only have `sc.symbol`. We
don't really need the `sc.function` apart from when formatting
arguments.
For the function arguments case I added a fallback that will just print
the arguments we get from the demangler (which is what LLDB does for
stacktraces with no debug-info anyway). Ideally we'd have a separate
`FormatEntity::Entry::Type::FunctionArguments` that will just print the
arguments from the demangler and have something like the following in
the `plugin.cplusplus.display.function-name-format`:
```
{ ${function.formatted-arguments} || ${function.arguments} }
```
I.e., when we can't format the arguments, print the ones from the
demangler. But we currently don't have the `||` operator in the
frame-format language yet.
Adds the new `plugin.cplusplus.display.function-name-format` setting and makes the `${function.name-with-args}` query it for formatting the function name.
One caveat is that the setting can't itself be set to `${function.name-with-args}` because that would cause infinite recursion and blow the stack. I added an XFAILed test-case for it and will address it in a follow-up patch.
https://github.com/llvm/llvm-project/pull/131836
Adds new frame-format variables and implements them in the CPlusPlusLanguage plugin.
We use the `DemangledNameInfo` type to retrieve the necessary part of the demangled name.
https://github.com/llvm/llvm-project/pull/131836
When a frame is inlined, LLDB will display its name in backtraces as
follows:
```
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.3
* frame #0: 0x0000000100000398 a.out`func() [inlined] baz(x=10) at inline.cpp:1:42
frame #1: 0x0000000100000398 a.out`func() [inlined] bar() at inline.cpp:2:37
frame #2: 0x0000000100000398 a.out`func() at inline.cpp:4:15
frame #3: 0x00000001000003c0 a.out`main at inline.cpp:7:5
frame #4: 0x000000026eb29ab8 dyld`start + 6812
```
The longer the names get the more confusing this gets because the first
function name that appears is the parent frame. My assumption (which may
need some more surveying) is that for the majority of cases we only care
about the actual frame name (not the parent). So this patch removes all
the special logic that prints the parent frame.
Another quirk of the current format is that the inlined frame name does
not abide by the `${function.name-XXX}` format variables. We always just
print the raw demangled name. With this patch, we would format the
inlined frame name according to the `frame-format` setting (see the
test-cases).
If we really want to have the `parentFrame [inlined] inlinedFrame`
format, we could expose it through a new `frame-format` variable (e..g.,
`${function.inlined-at-name}` and let the user decide where to place
things.
Both the `CPlusPlusLanguage` plugins and the Swift language plugin
already assume the `sc != nullptr`. And all `FormatEntity` callsites of
`GetFunctionDisplayName` already check for nullptr before passing `sc`.
This patch makes this pre-condition explicit by changing the parameter
to `const SymbolContext &`. This will help with some upcoming changes in
this area.
Same cleanup as in https://github.com/llvm/llvm-project/pull/135031. It
pretty much is the same code that we had to duplicate in the language
plugin. Maybe eventually we'll find a way of getting rid of the
duplication.
Reverts llvm/llvm-project#132274
Broke a test on LLDB Widows on Arm:
https://lab.llvm.org/buildbot/#/builders/141/builds/7726
```
FAIL: test_dwarf (lldbsuite.test.lldbtest.TestExternCSymbols.test_dwarf)
<...>
self.assertTrue(self.res.Succeeded(), msg + output)
AssertionError: False is not true : Command 'expression -- foo()' did not return successfully
Error output:
error: Couldn't look up symbols:
int foo(void)
Hint: The expression tried to call a function that is not present in the target, perhaps because it was optimized out by the compiler.
```
ValueObject is part of lldbCore for historical reasons, but conceptually
it deserves to be its own library. This does introduce a (link-time) circular
dependency between lldbCore and lldbValueObject, which is unfortunate
but probably unavoidable because so many things in LLDB rely on
ValueObject. We already have cycles and these libraries are never built
as dylibs so while this doesn't improve the situation, it also doesn't
make things worse.
The header includes were updated with the following command:
```
find . -type f -exec sed -i.bak "s%include \"lldb/Core/ValueObject%include \"lldb/ValueObject/ValueObject%" '{}' \;
```
These proxies are returned by operator[](...). These proxies all
"behave" the same. They store a pointer to the data of the valarray they
are a proxy for and they have an internal array of indices. This
internal array is considered its contents.
The `(( )?&)?` appears to match types which are references. However lldb
can load the
correct data formatters without having to pattern match against a `&`
suffix.
The suffix may have been needed at one point, but it's no longer needed.
