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%" '{}' \;
```
This patch is in preparation for the `__compressed_pair` refactor in
https://github.com/llvm/llvm-project/pull/76756.
This is mostly reviewable now. With the new layout we no longer need to
unwrap the `__compressed_pair`. Instead, we just need to look for child
members. E.g., to get to the underlying pointer of `std::unique_ptr` we
no longer do,
```
GetFirstValueOfCXXCompressedPair(GetChildMemberWithName("__ptr_"))
```
but instead do
```
GetChildMemberWithName("__ptr_")
```
We need to be slightly careful because previously the
`__compressed_pair` had a member called `__value_`, whereas now
`__value_` might be a member of the class that used to hold the
`__compressed_pair`. So before unwrapping the pair, we added checks for
`isOldCompressedLayout` (not sure yet whether folding this check into
`GetFirstValueOfCXXCompressedPair` is better).
Similar to how we moved the `std::map::iterator` formatter in
https://github.com/llvm/llvm-project/pull/97687, do the same for
`std::unordered_map::iterator`.
Again the `unordered_map` and `unordered_map::iterator` formatters try
to do very similar things: retrieve data out of the map. The iterator
formatter does this in a fragile way (similar to how `std::map` does it,
see https://github.com/llvm/llvm-project/pull/97579). Thus we will be
refactoring the `std::unordered_map::iterator` in upcoming patches.
Having it in `LibCxxUnorderedMap` will allow us to re-use some of the
logic (and we won't have to repeat some of the clarification comments).
The two formatters follow very similar techniques to retrieve data out
of the map. We're changing this for `std::map` in
https://github.com/llvm/llvm-project/pull/97579 and plan to change it in
the same way for the iterator formatter. Having them in the same place
will allow us to re-use some of the logic (and we won't have to repeat
some of the clarification comments).
Found while skimming this code. Don't have a reproducible test case for
this but the nullptr check should clearly occur before we try to
dereference `location_sp`.
This is another step towards supporting DWARF5 checksums and inline
source code in LLDB. This is a reland of #85468 but without the
functional change of storing the support file from the line table (yet).
Change GetNumChildren()/CalculateNumChildren() methods return
llvm::Expected
This is an NFC change that does not yet add any error handling or change
any code to return any errors.
This is the second big change in the patch series started with
https://github.com/llvm/llvm-project/pull/83501
A follow-up PR will wire up error handling.
Change GetNumChildren()/CalculateNumChildren() methods return
llvm::Expected
This is an NFC change that does not yet add any error handling or change
any code to return any errors.
This is the second big change in the patch series started with
https://github.com/llvm/llvm-project/pull/83501
A follow-up PR will wire up error handling.
This formatter
https://github.com/llvm/llvm-project/pull/78609
was originally passing the signed seconds (which can refer to times in
the past) with an unsigned printf formatter, and had tests that expected
to see negative values from the printf which always failed on macOS. I'm
not clear how they ever passed on any platform.
Fix the printf to print seconds as a signed value, and re-enable the
tests.
This patch fixes:
lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp:1108:39: error:
format specifies type 'long long' but the argument has type
'std::time_t' (aka 'long') [-Werror,-Wformat]
lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp:1116:64: error:
format specifies type 'long long' but the argument has type
'std::time_t' (aka 'long') [-Werror,-Wformat]
This fixes:
```
[6331/7452] Building CXX object tools\lldb\source\Plugins\Language\CPlusPlus\CMakeFiles\lldbPluginCPlusPlusLanguage.dir\LibCxx.cpp.obj
C:\git\llvm-project\lldb\source\Plugins\Language\CPlusPlus\LibCxx.cpp(1108,38): warning: format specifies type 'long' but the argument has type 'std::time_t' (aka 'long long') [-Wformat]
1108 | stream.Printf("timestamp=%ld s", seconds);
| ~~~ ^~~~~~~
| %lld
C:\git\llvm-project\lldb\source\Plugins\Language\CPlusPlus\LibCxx.cpp(1116,63): warning: format specifies type 'long' but the argument has type 'std::time_t' (aka 'long long') [-Wformat]
1116 | stream.Printf("date/time=%s timestamp=%ld s", str.data(), seconds);
| ~~~ ^~~~~~~
| %lld
2 warnings generated.
```
This is a followup of #76983 and adds the libc++ data formatters for
- weekday,
- weekday_indexed,
- weekday_last,
- month_weekday,
- month_weekday_last,
- year_month,
- year_month_day_last
- year_month_weekday, and
- year_month_weekday_last.
This adds a subset of the C++20 calendar data formatters:
- day,
- month,
- year,
- month_day,
- month_day_last, and
- year_month_day.
A followup patch will add the missing calendar data formatters:
- weekday,
- weekday_indexed,
- weekday_last,
- month_weekday,
- month_weekday_last,
- year_month,
- year_month_day_last
- year_month_weekday, and
- year_month_weekday_last.
This doesn't really use fast comparison or string uniqueness. In fact,
all of the current callers pass an empty string for type_name. The only
reason I don't remove it is because it looks like it is used downstream
for swift.
Differential Revision: https://reviews.llvm.org/D153810
Existing callers of `GetChildAtIndex` pass true for can_create. This change
makes true the default value, callers don't have to pass an opaque true.
See also D151966 for the same change to `GetChildMemberWithName`.
Differential Revision: https://reviews.llvm.org/D152031
It turns out all existing callers of `GetChildMemberWithName` pass true for `can_create`.
This change makes `true` the default value, callers don't have to pass an opaque true.
Differential Revision: https://reviews.llvm.org/D151966
Following D151810, this changes `GetChildAtNamePath` to take a path of `StringRef`
values instead of `ConstString`.
Differential Revision: https://reviews.llvm.org/D151813
As with D151615, which changed `GetIndexOfChildMemberWithName` to take a `StringRef`
instead of a `ConstString`, this change does the same for `GetIndexOfChildWithName`.
Differential Revision: https://reviews.llvm.org/D151811
`GetChildMemberWithName` does not need a `ConstString`. This change makes the function
take a `StringRef` instead, which alleviates the need for callers to construct a
`ConstString`. I don't expect this change to improve performance, only ergonomics.
This is in support of Alex's effort to replace `ConstString` where appropriate.
There are related `ValueObject` functions that can also be changed, if this is accepted.
Differential Revision: https://reviews.llvm.org/D151615
The unique_ptr prettyprinter calls `GetValueOfLibCXXCompressedPair`,
which looks for a `__value_` child. However, when the second value in
the compressed pair is not an empty class, there are two `__value_`
children because `__compressed_pair` derives twice from
`__compressed_pair_elem`, one for each member of the pair. And then the
lookup fails because it's ambiguous.
This patch makes the following changes:
- Rename `GetValueOfLibCXXCompressedPair` to
`GetFirstValueOfLibCXXCompressedPair`, and add a similar function to
get the second value. Put both functions in
Plugin/Language/CPlusPlus/LibCxx.cpp because it seems inappropriate to
have libcxx-specific helpers separate from all the libcxx-dependent
code.
- Read the second value of the `__ptr_` pair and display a "deleter"
child in the unique_ptr synthetic child provider, when available.
- Add a test case for the non-empty deleter case.
Differential Revision: https://reviews.llvm.org/D148662
The current interface theoretically could lead to a use-after-free
when a client holds on to the returned pointer. Fix this by returning
a shared_ptr to the scratch typesystem.
rdar://103619233
Differential Revision: https://reviews.llvm.org/D141100
When a process gets restarted TypeSystem objects associated with it
may get deleted, and any CompilerType objects holding on to a
reference to that type system are a use-after-free in waiting. Because
of the SBAPI, we don't have tight control over where CompilerTypes go
and when they are used. This is particularly a problem in the Swift
plugin, where the scratch TypeSystem can be restarted while the
process is still running. The Swift plugin has a lock to prevent
abuse, but where there's a lock there can be bugs.
This patch changes CompilerType to store a std::weak_ptr<TypeSystem>.
Most of the std::weak_ptr<TypeSystem>* uglyness is hidden by
introducing a wrapper class CompilerType::WrappedTypeSystem that has a
dyn_cast_or_null() method. The only sites that need to know about the
weak pointer implementation detail are the ones that deal with
creating TypeSystems.
rdar://101505232
Differential Revision: https://reviews.llvm.org/D136650
This patch adds a formatter for libcxx's `std::unordered_map` iterators.
The implementation follows a similar appraoch to the `std::map` iterator
formatter. I was hesistant about coupling the two into a common
implementation since the libcxx layouts might change for one of the
the containers but not the other.
All `std::unordered_map` iterators are covered with this patch:
1. const/non-const key/value iterators
2. const/non-const bucket iterators
Note that, we currently don't have a formatter for `std::unordered_map`.
This patch doesn't change that, we merely add support for its iterators,
because that's what Xcode users requested. One can still see contents
of `std::unordered_map`, whereas with iterators it's less ergonomic.
**Testing**
* Added API test
Differential Revision: https://reviews.llvm.org/D129364
Precise string layout has changed a lot recently, but a long of these
changes did not have any effect on the usages of its fields -- e.g.
introduction/removal of an anonymous struct or union does not change the
way one can access the field in C++. Our name-based variable lookup
rules (deliberately) copy the C++ semantics, which means these changes
would have been invisible to the them, if only we were using name-based
lookup.
This patch replaces the opaque child index accesses with name-based
lookups, which allows us to greatly simplify the data formatter code.
The formatter continues to support all the string layouts that it
previously supported.
It is unclear why the formatter was not using this approach from the
beginning. I would speculate that the original version was working
around some (now fixed) issue with anonymous members or base classes,
and the subsequent revisions stuck with that approach out of inertia.
Differential Revision: https://reviews.llvm.org/D129490
D128285 only changed the stable (v1) layout, so the matching change in
D128694 broke the formatting of the unstable strings. This fixes that,
and ensures compatibility with all older layouts as well.
This patch changes the C++ `std::string` dataformatter to reflect
internal layout changes following D128285.
Now, in short-mode strings, in order to access the `__size_` and
`__is_long_` attributes, we need to access a packed anonymous struct,
which introduces another indirection.
We need to do the same in order to access the `__cap_` field for
long-mode strings.
This should fix the various test failures that are happening on
GreenDragon:
https://green.lab.llvm.org/green/job/lldb-cmake/44918/
rdar://96010248
Differential Revision: https://reviews.llvm.org/D128694
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
string points to unaccessible memory.
The formatter tries to get the data field of the std::string, and to
check whether that fails it just checks that the ValueObjectSP
returned is not empty. But we never return empty ValueObjectSP's to
indicate failure, since doing so would lose the Error object that
tells you why fetching the ValueObject failed.
This patch adds a check for ValueObject::GetError().Success().
I also added a test case for this failure, and reworked the test case
a bit (to use run_to_source_breakpoint). I also renamed a couple of
single letter locals which don't follow the lldb coding conventions.
Differential Revision: https://reviews.llvm.org/D108228
The code needs more TLC, but for now I've tried making only the changes
that are necessary to get the tests passing -- postponing the more
invasive changes after I create a more comprehensive test.
In a couple of places I have changed the index-based element accesses to
name-based ones (as these are less sensitive to code perturbations). I'm
not sure why the code was using indexes in the first place, but I've
(manually) tested the change with various libc++ versions, and found no
issues with this approach.
Differential Revision: https://reviews.llvm.org/D124113
