Commit Graph

377 Commits

Author SHA1 Message Date
Pavel Labath b725142c8d [lldb] Fix type conversion in the Scalar getters
Summary:
The Scalar class claims to follow the C type conversion rules. This is
true for the Promote function, but it is not true for the implicit
conversions done in the getter methods.

These functions had a subtle bug: when extending the type, they used the
signedness of the *target* type in order to determine whether to do
sign-extension or zero-extension. This is not how things work in C,
which uses the signedness of the *source* type. I.e., C does
(sign-)extension before it does signed->unsigned conversion, and not the
other way around.

This means that: (unsigned long)(int)-1
      is equal to (unsigned long)0xffffffffffffffff
      and not (unsigned long)0x00000000ffffffff

Unsurprisingly, we have accumulated code which depended on this
inconsistent behavior. It mainly manifested itself as code calling
"ULongLong/SLongLong" as a way to get the value of the Scalar object in
a primitive type that is "large enough". Previously, the ULongLong
conversion did not do sign-extension, but now it does.

This patch makes the Scalar getters consistent with the declared
semantics, and fixes the couple of call sites that were using it
incorrectly.

Reviewers: teemperor, JDevlieghere

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D82772
2020-07-02 18:02:57 +02:00
Eric Christopher efb328f674 As part of using inclusive language with the llvm project,
migrate away from the use of blacklist and whitelist.
2020-06-19 14:48:48 -07:00
Med Ismail Bennani 0eba9de71e [lldb/Dataformatter] Add support to CF{Dictionary,Set}Ref types
This patch improves data formatting for CFDictionaryRef and CFSetRef.
It uses the same data-formatter as NSCFDictionaries and NSCFSets introduced
previously but did require some adjustments in Core::ValueObject.

Since the "Ref" types are opaque pointers to the actual CF containers, if the
value object has a synthetic value, lldb will use the opaque pointer's pointee
type to create the new ValueObjectChild needed to dereference the ValueObject.
This allows the "Ref" types to behaves the same as CF containers when used with
the `frame variable` command, the SBAPI or in Xcode's variable inspector.

This patch also adds support for incomplete types in ValueObject.

rdar://53104287

Differential Revision: https://reviews.llvm.org/D79554

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2020-05-15 22:14:39 +02:00
Raphael Isemann 7b1f1cf1cf [lldb] Remove 'use_synthetic' parameters in ValueObject code
Summary:
`CalculateSyntheticValue` and `GetSyntheticValue` have a `use_synthetic` parameter
that makes the function do nothing when it's false. We obviously always pass true
to the function (or check that the value we pass is true), because there really isn't
any point calling with function with a `false`. This just removes all of this.

Reviewers: labath, JDevlieghere, davide

Reviewed By: davide

Subscribers: davide

Differential Revision: https://reviews.llvm.org/D79568
2020-05-08 21:17:32 +02:00
Raphael Isemann d7c2c2ed79 [lldb][NFC] Also initialize language_flags in ValueObject::Dereference
We currently rely on the TypeSystem implementation to initialize this value
with 0 in the GetChildCompilerTypeAtIndex call below. Let's just initialize
this variable like the rest.
2020-05-07 17:52:12 +02:00
Jaroslav Sevcik 177dd63c8d Data formatters: fix detection of C strings
Summary:
Detection of C strings does not work well for pointers. If the value object holding a (char*) pointer does not have an address (e.g., if it is a temp), the value is not considered a C string and its formatting is left to DumpDataExtractor rather than the special handling in  ValueObject::DumpPrintableRepresentation. This leads to inconsistent outputs, e.g., in escaping non-ASCII characters. See the test for an example; the second test expectation is not met (without this patch). With this patch, the C string detection only insists that the pointer value is valid. The patch makes the code consistent with how the pointer is obtained in ValueObject::ReadPointedString.

Reviewers: teemperor

Reviewed By: teemperor

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D76650
2020-03-24 14:25:59 +01:00
Jim Ingham 67d67ebe8f Internal expressions shouldn't increment the result variable numbering.
There an option: EvaluateExpressionOptions::SetResultIsInternal to indicate
whether the result number should be returned to the pool or not.  It
got broken when the PersistentExpressionState was refactored.

This fixes the issue and provides a test of the behavior.

Differential Revision: https://reviews.llvm.org/D76532
2020-03-23 13:30:37 -07:00
Pavel Labath 0863f67579 [lldb] Remove DataExtractor::GetPointer
This function is equivalent to GetAddress, but getAddress is also
present on the llvm version of the data extractor.
2020-02-18 10:38:41 +01:00
Raphael Isemann 30ce956aec [lldb][NFC] Remove GetConstTypeName and GetConstQualifiedTypeName from CompilerType
Beside these two functions just being wrappers around GetTypeName they are also
just a leftover from migrating the CompilerType interface to ConstString.
2020-02-12 09:49:39 +01:00
Pavel Labath 363f05b83d [lldb] Delete the SharingPtr class
Summary:
The only use of this class was to implement the SharedCluster of ValueObjects.
However, the same functionality can be implemented using a regular
std::shared_ptr, and its little-known "sub-object pointer" feature, where the
pointer can point to one thing, but actually delete something else when it goes
out of scope.

This patch reimplements SharedCluster using this feature --
SharedClusterPointer::GetObject now returns a std::shared_pointer which points
to the ValueObject, but actually owns the whole cluster. The only change I
needed to make here is that now the SharedCluster object needs to be created
before the root ValueObject. This means that all private ValueObject
constructors get a ClusterManager argument, and their static Create functions do
the create-a-manager-and-pass-it-to-value-object dance.

Reviewers: teemperor, JDevlieghere, jingham

Subscribers: mgorny, jfb, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D74153
2020-02-11 13:23:18 +01:00
Raphael Isemann 642bc15dd7 [lldb][NFC] Remove several inefficient ConstString -> const char * -> StringRef conversions
StringRef will call strlen on the C string which is inefficient (as ConstString already
knows the string lenght and so does StringRef). This patch replaces all those calls
with GetStringRef() which doesn't recompute the length.
2020-02-11 09:14:41 +01:00
Alex Langford 3014efe071 [lldb] Remove unused parameter from ValueObject::GetExpressionPath
I previously removed the code in ValueObject::GetExpressionPath that
took advantage of the parameter `qualify_cxx_base_classes`. As a result,
this is now unused and can be removed.
2020-02-03 10:50:38 -08:00
Alex Langford e1451a724d [lldb][NFCI] Rename variable in ValueObject 2020-01-30 16:53:01 -08:00
Alex Langford 71b022ee55 [lldb] Remove unused header from ValueObject.cpp
In commit 5eaf44f99f I removed the last
instance of TypeSystemClang from ValueObject, so the header is no longer
needed.
2020-01-28 16:13:21 -08:00
Benjamin Kramer adcd026838 Make llvm::StringRef to std::string conversions explicit.
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.
2020-01-28 23:25:25 +01:00
Alex Langford 5eaf44f99f [lldb] Delete ValueObject::GetBaseClassPath
Summary:
This method has exactly one call site, which is only actually executed
if `ValueObject::IsBaseClass` returns false. However, the first thing
that `ValueObject::GetBaseClassPath` does is check if `ValueObject::IsBaseClass`
is true. Because this can never be the case, this method always returns false
and is therefore effectively dead.

Differential Revision: https://reviews.llvm.org/D73517
2020-01-28 14:11:53 -08:00
Raphael Isemann 808142876c [lldb][NFC] Fix all formatting errors in .cpp file headers
Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).

This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).

Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D73258
2020-01-24 08:52:55 +01:00
Raphael Isemann 6e3b0cc2fb [lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).

I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.

Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai

Reviewed By: clayborg, labath, xiaobai

Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 10:09:14 +01:00
Fred Riss 0478eadf73 [lldb/DataFormatters] Fix the $$deference$$ synthetic child
Summary:
The ValueObject code checks for a special `$$dereference$$` synthetic
child to allow formatter providers to implement a natural
dereferencing behavior in `frame variable` for objects like smart
pointers.

This support was broken when used directly throught the Python API and
not trhough `frame variable`. The reason is that
SBFrame.FindVariable() will return by default the synthetic variable
if it exists, while `frame variable` will not do this eagerly. The
code in `ValueObject::Dereference()` accounted for the latter but not
for the former. The fix is trivial. The test change includes
additional covergage for the already-working bahevior as it wasn't
covered by the testsuite before.

This commit also adds a short piece of documentatione explaining that
it is possible (even advisable) to provide this synthetic child
outstide of the range of the normal children.

Reviewers: jingham

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D73053
2020-01-21 13:35:55 -08:00
Jonas Devlieghere 4e26cf2cfb [lldb/CMake] Rename LLDB_DISABLE_PYTHON to LLDB_ENABLE_PYTHON
This matches the naming scheme used by LLVM and all the other optional
dependencies in LLDB.

Differential revision: https://reviews.llvm.org/D71482
2019-12-13 13:41:11 -08:00
Adrian Prantl ee64dfd953 Remove TypeValidators (NFC in terms of the testsuite)
This is a half-implemented feature that as far as we can tell was
never used by anything since its original inclusion in 2014. This
patch removes it to make remaining the code easier to understand.

Differential Revision: https://reviews.llvm.org/D71310
2019-12-11 09:27:12 -08:00
Jonas Devlieghere 59998b7b7f [lldb/Host] Use Host/Config.h entries instead of a global define.
As suggested by Pavel in a code review:

> Can we replace this (and maybe python too, while at it) with a
> Host/Config.h entry? A global definition means that one has to
> recompile everything when these change in any way, whereas in
> practice only a handful of files need this..

Differential revision: https://reviews.llvm.org/D71280
2019-12-10 11:16:52 -08:00
Adrian Prantl 3ac6863efb [ValueObject] Upstream early exit from swift-lldb. (NFC) 2019-11-05 12:43:00 -08:00
Adrian Prantl de5417f81d [ValueObject] Upstream initialization from swift-lldb.
This is a non-Swift-specific change in swift-lldb that seems to be
useful for remote debugging. If does in fact turn out to be redundant
we can remove it from llvm.org and then it will disappear in
swift-lldb, too.
2019-11-05 12:36:14 -08:00
Alex Langford db542455dc [Symbol] Change ClangASTContext::GetCXXClassName return type
Summary:
Instead of filling out a std::string and returning a bool to indicate
success, returning a std::string directly and testing to see if it's
empty seems like a cleaner solution overall.

Differential Revision: https://reviews.llvm.org/D69641
2019-10-31 11:57:37 -07:00