rdar://143164164
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%" '{}' \;
```
- Remove unused parameter `valobj` (I checked downstream, not even swift is using it). - Return a std::pair<StringRef, StringRef> insted of having 2 out parameter strings. - Remove the use of ConstStrings. This change was primarily mechanical except in `ObjCLanguage::GetFormatterPrefixSuffix`. To keep this fast, we construct an llvm::StringMap<std::pair<StringRef, StringRef>> so that we can look things up quickly. There is some amount of cost to setting up the map the first time it is called, but subsequent lookups should be as fast as a hash + string comparison (the cost of looking up something in an llvm::StringMap). Differential Revision: https://reviews.llvm.org/D151603
Simplify getting the length of `NSPathStore2` strings. `NSStringSummaryProvider` uses a single field from `NSPathStore2` instances, its first ivar: `_lengthAndRefCount`. This change uses `GetSyntheticChildAtOffset` to replace the use of `ProcessStructReader`, and removes the hard coded `CompilerType` definition of `NSPathStore2`. Differential Revision: https://reviews.llvm.org/D116461
The StringPrinter class was using a Process instance to read memory. This automatically prevented it from working before starting the program. This patch changes the class to use the Target object for reading memory, as targets are always available. This required moving ReadStringFromMemory from Process to Target. This is sufficient to make frame/target variable work, but further changes are necessary for the expression evaluator. Preliminary analysis indicates the failures are due to the expression result ValueObjects failing to provide an address, presumably because we're operating on file addresses before starting. I haven't looked into what would it take to make that work. Differential Revision: https://reviews.llvm.org/D113098
Also add some documentation while I'm at it.
Summary:
Languages can have different ways of formatting special characters.
E.g. when debugging C++ code a string might look like "\b", but when
debugging Swift code the same string would look like "\u{8}".
To make this work, plugins override GetStringPrinterEscapingHelper.
However, because there's a large amount of subtly divergent work done in
each override, we end up with large amounts of duplicated code. And all
the memory smashers fixed in one copy of the logic (see D73860) don't
get fixed in the others.
IMO the GetStringPrinterEscapingHelper is overly general and hard to
use. I propose deleting it and replacing it with an EscapeStyle enum,
which can be set as needed by each plugin.
A fix for some swift-lldb memory smashers falls out fairly naturally
from this deletion (https://github.com/apple/llvm-project/pull/1046). As
the swift logic becomes really tiny, I propose moving it upstream as
part of this change. I've added unit tests to cover it.
rdar://61419673
Reviewers: JDevlieghere, davide
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77843
(This is D68010 but I also set the new parameter in LibStdcpp.cpp to fix the Debian tests). Summary: Printing a summary for an empty NSPathStore2 string currently prints random bytes behind the empty string pointer from memory (rdar://55575888). It seems the reason for this is that the SourceSize parameter in the `ReadStringAndDumpToStreamOptions` - which is supposed to contain the string length - actually uses the length 0 as a magic value for saying "read as much as possible from the buffer" which is clearly wrong for empty strings. This patch adds another flag that indicates if we have know the string length or not and makes this behaviour dependent on that (which seemingly was the original purpose of this magic value). Reviewers: aprantl, JDevlieghere, shafik Reviewed By: aprantl Subscribers: christof, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68010
This reverts commit 939ca455e72e822450013eff37c9ea7746850350.
This failed on the debian bot for some reason:
File "/home/worker/lldb-x86_64-debian/lldb-x86_64-debian/llvm-project/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/string/TestDataFormatterStdString.py", line 67, in test_with_run_command
"s summary wrong")
AssertionError: 'L"hello world! מזל טוב!\\0!\\0!!!!\\0\\0A\\0\\U0000fffd\\U0000fffd\\U0000fffd\\ [truncated]... != 'L"hello world! מזל טוב!"'
Diff is 2156 characters long. Set self.maxDiff to None to see it. : s summary wrong
Summary: Printing a summary for an empty NSPathStore2 string currently prints random bytes behind the empty string pointer from memory (rdar://55575888). It seems the reason for this is that the SourceSize parameter in the `ReadStringAndDumpToStreamOptions` - which is supposed to contain the string length - actually uses the length 0 as a magic value for saying "read as much as possible from the buffer" which is clearly wrong for empty strings. This patch adds another flag that indicates if we have know the string length or not and makes this behaviour dependent on that (which seemingly was the original purpose of this magic value). Reviewers: aprantl, JDevlieghere, shafik Reviewed By: aprantl Subscribers: christof, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68010