| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
(#161499)
We've been seen (very sporadic) lifetime issues around this area. Here's
an example backtrace:
```
[ 8] 0x0000000188e56743 libsystem_platform.dylib`_sigtramp + 55
[ 9] 0x00000001181e041f LLDB`lldb_private::CPlusPlusLanguage::SymbolNameFitsToLanguage(lldb_private::Mangled) const [inlined] unsigned long std::1::constexpr_strlen[abi:nn200100]<char>(char const*) + 7 at constexpr_c_functions.h:63:10
[ 9] 0x00000001181e0418 LLDB`lldb_private::CPlusPlusLanguage::SymbolNameFitsToLanguage(lldb_private::Mangled) const [inlined] std::__1::char_traits<char>::length[abi:nn200100](char const*) at char_traits.h:232:12
[ 9] 0x00000001181e0418 LLDB`lldb_private::CPlusPlusLanguage::SymbolNameFitsToLanguage(lldb_private::Mangled) const [inlined] llvm::StringRef::StringRef(char const*) at StringRef.h:90:33
[ 9] 0x00000001181e0418 LLDB`lldb_private::CPlusPlusLanguage::SymbolNameFitsToLanguage(lldb_private::Mangled) const [inlined] llvm::StringRef::StringRef(char const*) at StringRef.h:92:38
[ 9] 0x00000001181e0418 LLDB`lldb_private::CPlusPlusLanguage::SymbolNameFitsToLanguage(lldb_private::Mangled) const + 20 at CPlusPlusLanguage.cpp:68:62
```
Looks like we're calling `strlen` on a nullptr. I stared at this
codepath for a while but am still not sure how that could happen unless
the underlying `ConstString` somehow pointed to corrupted data.
But `SymbolNameFitsToLanguage` does some roundtripping through a `const
char*` before calling `GetManglingScheme`. No other callsite does this
and it just seems redundant.
This patch cleans this up.
rdar://161128180
|
|
NFC. (#159327)
This avoids the following kind of warning with GCC:
warning: control reaches end of non-void function [-Wreturn-type]
|
|
C++11 allows the use of Universal Character Names (UCNs) in identifiers,
including function names.
According to the spec the behavior of std::isalpha(ch) and
std::isalnum(ch) is undefined if the argument's value is neither
representable as unsigned char nor equal to EOF. To use these functions
safely with plain chars (or signed chars), the argument should first be
converted to unsigned char.
|
|
allocators (#156050)
This came up in https://github.com/llvm/llvm-project/issues/155691.
For `std::basic_string` our formatter matching logic required the
allocator template parameter to be a `std::allocator`. There is no
compelling reason (that I know of) why this would be required for us to
apply the existing formatter to the string. We don't check the
`allocator` parameter for other STL containers either. This meant that
`std::string` that used custom allocators wouldn't be formatted. This
patch relaxes the regex for `basic_string`.
|
|
Part of https://github.com/llvm/llvm-project/pull/149827
Allows us to use the mangling substitution facilities in
CPlusPlusLanguage but also SymbolFileDWARF.
Added tests now that they're "public".
|
|
The current implementation of
CPlusPlusLanguage::SymbolNameFitsToLanguage will return true if the
symbol is mangled for any language that lldb knows about.
|
|
This way all the tracking is self-contained in `TrackingOutputBuffer`
and we can test the `SuffixRange` properly.
|
|
DemangledNameInfo components and use them in tests (#152134)
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.
|
|
Adds summaries for `std::{,w,u8,u16,u32}string_view`s from MSVC's STL. A
few functions from the string formatting can be reused.
Towards #24834.
|
|
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](https://github.com/microsoft/STL/blob/313964b78a8fd5a52e7965e13781f735bcce13c5/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`](https://github.com/microsoft/STL/blob/313964b78a8fd5a52e7965e13781f735bcce13c5/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
https://github.com/microsoft/STL/blob/313964b78a8fd5a52e7965e13781f735bcce13c5/stl/inc/xtree.
Towards #24834.
|
|
Adds formatters for MSVC STL's unordered containers. This one is
relatively simple, because it can reuse the `std::list` synthetic
children. The unordered containers (aka
[`_Hash`](https://github.com/microsoft/STL/blob/313964b78a8fd5a52e7965e13781f735bcce13c5/stl/inc/xhash#L327))
contain a
[`_List`](https://github.com/microsoft/STL/blob/313964b78a8fd5a52e7965e13781f735bcce13c5/stl/inc/xhash#L2012)
which contains all elements (and is used for iterating through the
container).
Towards https://github.com/llvm/llvm-project/issues/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 children for `std::optional` from MSVC's STL. Most of the
machinery for `std::optional` is already there.
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](https://github.com/llvm/llvm-project/blob/3092b765ba0b2d20bd716944dda86ea8e4ad12e3/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>`](https://github.com/microsoft/STL/blob/313964b78a8fd5a52e7965e13781f735bcce13c5/stl/debugger/STL.natvis#L1193-L1205)
- [NatVis for
`std::vector<bool>`](https://github.com/microsoft/STL/blob/313964b78a8fd5a52e7965e13781f735bcce13c5/stl/debugger/STL.natvis#L1167-L1179)
Towards #24834.
|
|
Adds synthetic children for MSVC STL's
[`std::tuple`](https://github.com/microsoft/STL/blob/313964b78a8fd5a52e7965e13781f735bcce13c5/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](https://github.com/microsoft/STL/blob/313964b78a8fd5a52e7965e13781f735bcce13c5/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](https://github.com/microsoft/STL/blob/313964b78a8fd5a52e7965e13781f735bcce13c5/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`.
|
|
(#147139)
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
|
|
(#147174)
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
|
|
(#147140)
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.
|
|
Fix an error message which incorrectly says that we failed to handle a
`basename`. It should say `formatted-arguments` instead.
|
|
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).
|
|
(#140727)
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
|
|
without debug-info" (#137757)
This reverts commit da7099290cea7d11b83da01adda8afeb3bcd5362.
Same as the original PR. The failing test-case was resolved in https://github.com/llvm/llvm-project/pull/137763
|
|
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)`.
|
|
without debug-info" (#137757)
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
```
|
|
debug-info (#137408)
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.
|
|
|
|
(#131836)
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
|
|
dependencies (#135033)
The original PR is #132274.
Co-authored-by: @bulbazord Alex Langford
|
|
available (#135343)
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.
|
|
reference (#135536)
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.
|
|
helpers and use LLVM style (#135331)
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.
|
|
dependencies" (#134995)
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.
```
|
|
dependencies (#132274)
This patch addresses the issue #129543.
After this patch the size of lldb-server is reduced by 9MB.
Co-authored-by: @bulbazord Alex Langford
|
|
in libcxx container summary (#125294)
This has two changes:
1. Set show value for libcxx and libstdcxx summary provider. This will
print the pointer value for both pointer type and reference type.
2. Remove pointer value printing in libcxx container summary.
Discussion:
https://discourse.llvm.org/t/lldb-hides-raw-pointer-value-for-libcxx-and-libstdcxx-pointer-types-in-summary-string/84226
|
|
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.
|
|
|
