[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 15:23:27 +08:00
|
|
|
//===-- ValueObjectMemory.cpp ---------------------------------------------===//
|
2011-04-16 08:01:13 +08:00
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2011-04-16 08:01:13 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "lldb/Core/ValueObjectMemory.h"
|
|
|
|
#include "lldb/Core/Value.h"
|
|
|
|
#include "lldb/Core/ValueObject.h"
|
|
|
|
#include "lldb/Symbol/Type.h"
|
|
|
|
#include "lldb/Target/ExecutionContext.h"
|
|
|
|
#include "lldb/Target/Target.h"
|
2018-11-12 07:16:43 +08:00
|
|
|
#include "lldb/Utility/DataExtractor.h"
|
|
|
|
#include "lldb/Utility/Scalar.h"
|
|
|
|
#include "lldb/Utility/Status.h"
|
|
|
|
#include "lldb/lldb-types.h"
|
|
|
|
#include "llvm/Support/ErrorHandling.h"
|
2017-04-07 05:28:29 +08:00
|
|
|
|
2021-05-26 18:19:37 +08:00
|
|
|
#include <cassert>
|
2018-11-12 07:16:43 +08:00
|
|
|
#include <memory>
|
2017-04-07 05:28:29 +08:00
|
|
|
|
|
|
|
namespace lldb_private {
|
|
|
|
class ExecutionContextScope;
|
|
|
|
}
|
2011-04-16 08:01:13 +08:00
|
|
|
|
2011-04-23 07:53:53 +08:00
|
|
|
using namespace lldb;
|
2011-04-16 08:01:13 +08:00
|
|
|
using namespace lldb_private;
|
|
|
|
|
2011-04-23 07:53:53 +08:00
|
|
|
ValueObjectSP ValueObjectMemory::Create(ExecutionContextScope *exe_scope,
|
2016-11-13 02:17:36 +08:00
|
|
|
llvm::StringRef name,
|
2011-04-23 07:53:53 +08:00
|
|
|
const Address &address,
|
|
|
|
lldb::TypeSP &type_sp) {
|
[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-04 10:05:21 +08:00
|
|
|
auto manager_sp = ValueObjectManager::Create();
|
|
|
|
return (new ValueObjectMemory(exe_scope, *manager_sp, name, address, type_sp))
|
|
|
|
->GetSP();
|
2011-04-23 07:53:53 +08:00
|
|
|
}
|
|
|
|
|
2011-04-28 06:04:39 +08:00
|
|
|
ValueObjectSP ValueObjectMemory::Create(ExecutionContextScope *exe_scope,
|
2016-11-13 02:17:36 +08:00
|
|
|
llvm::StringRef name,
|
2011-04-28 06:04:39 +08:00
|
|
|
const Address &address,
|
2015-08-12 06:53:00 +08:00
|
|
|
const CompilerType &ast_type) {
|
[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-04 10:05:21 +08:00
|
|
|
auto manager_sp = ValueObjectManager::Create();
|
|
|
|
return (new ValueObjectMemory(exe_scope, *manager_sp, name, address,
|
|
|
|
ast_type))
|
|
|
|
->GetSP();
|
2011-04-28 06:04:39 +08:00
|
|
|
}
|
|
|
|
|
2011-04-16 08:01:13 +08:00
|
|
|
ValueObjectMemory::ValueObjectMemory(ExecutionContextScope *exe_scope,
|
[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-04 10:05:21 +08:00
|
|
|
ValueObjectManager &manager,
|
2016-11-13 02:17:36 +08:00
|
|
|
llvm::StringRef name,
|
|
|
|
const Address &address,
|
2011-04-16 08:01:13 +08:00
|
|
|
lldb::TypeSP &type_sp)
|
[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-04 10:05:21 +08:00
|
|
|
: ValueObject(exe_scope, manager), m_address(address), m_type_sp(type_sp),
|
2015-09-24 11:54:50 +08:00
|
|
|
m_compiler_type() {
|
2011-04-16 08:01:13 +08:00
|
|
|
// Do not attempt to construct one of these objects with no variable!
|
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
2019-05-23 19:14:47 +08:00
|
|
|
assert(m_type_sp.get() != nullptr);
|
2011-07-30 03:53:35 +08:00
|
|
|
SetName(ConstString(name));
|
2021-02-12 04:57:04 +08:00
|
|
|
m_value.SetContext(Value::ContextType::LLDBType, m_type_sp.get());
|
2012-02-17 15:49:44 +08:00
|
|
|
TargetSP target_sp(GetTargetSP());
|
|
|
|
lldb::addr_t load_address = m_address.GetLoadAddress(target_sp.get());
|
2011-04-16 08:01:13 +08:00
|
|
|
if (load_address != LLDB_INVALID_ADDRESS) {
|
2021-02-12 04:57:04 +08:00
|
|
|
m_value.SetValueType(Value::ValueType::LoadAddress);
|
2011-04-16 08:01:13 +08:00
|
|
|
m_value.GetScalar() = load_address;
|
|
|
|
} else {
|
|
|
|
lldb::addr_t file_address = m_address.GetFileAddress();
|
|
|
|
if (file_address != LLDB_INVALID_ADDRESS) {
|
2021-02-12 04:57:04 +08:00
|
|
|
m_value.SetValueType(Value::ValueType::FileAddress);
|
2011-04-16 08:01:13 +08:00
|
|
|
m_value.GetScalar() = file_address;
|
|
|
|
} else {
|
|
|
|
m_value.GetScalar() = m_address.GetOffset();
|
2021-02-12 04:57:04 +08:00
|
|
|
m_value.SetValueType(Value::ValueType::Scalar);
|
2011-04-16 08:01:13 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2011-04-16 08:01:13 +08:00
|
|
|
}
|
|
|
|
|
2011-04-28 06:04:39 +08:00
|
|
|
ValueObjectMemory::ValueObjectMemory(ExecutionContextScope *exe_scope,
|
[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-04 10:05:21 +08:00
|
|
|
ValueObjectManager &manager,
|
2016-11-13 02:17:36 +08:00
|
|
|
llvm::StringRef name,
|
|
|
|
const Address &address,
|
2015-08-12 06:53:00 +08:00
|
|
|
const CompilerType &ast_type)
|
[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-04 10:05:21 +08:00
|
|
|
: ValueObject(exe_scope, manager), m_address(address), m_type_sp(),
|
2015-09-24 11:54:50 +08:00
|
|
|
m_compiler_type(ast_type) {
|
2011-04-28 06:04:39 +08:00
|
|
|
// Do not attempt to construct one of these objects with no variable!
|
2015-09-24 11:54:50 +08:00
|
|
|
assert(m_compiler_type.GetTypeSystem());
|
|
|
|
assert(m_compiler_type.GetOpaqueQualType());
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-02-17 15:49:44 +08:00
|
|
|
TargetSP target_sp(GetTargetSP());
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2011-07-30 03:53:35 +08:00
|
|
|
SetName(ConstString(name));
|
2015-09-24 11:54:50 +08:00
|
|
|
m_value.SetCompilerType(m_compiler_type);
|
2012-02-17 15:49:44 +08:00
|
|
|
lldb::addr_t load_address = m_address.GetLoadAddress(target_sp.get());
|
2011-04-28 06:04:39 +08:00
|
|
|
if (load_address != LLDB_INVALID_ADDRESS) {
|
2021-02-12 04:57:04 +08:00
|
|
|
m_value.SetValueType(Value::ValueType::LoadAddress);
|
2011-04-28 06:04:39 +08:00
|
|
|
m_value.GetScalar() = load_address;
|
|
|
|
} else {
|
|
|
|
lldb::addr_t file_address = m_address.GetFileAddress();
|
|
|
|
if (file_address != LLDB_INVALID_ADDRESS) {
|
2021-02-12 04:57:04 +08:00
|
|
|
m_value.SetValueType(Value::ValueType::FileAddress);
|
2011-04-28 06:04:39 +08:00
|
|
|
m_value.GetScalar() = file_address;
|
|
|
|
} else {
|
|
|
|
m_value.GetScalar() = m_address.GetOffset();
|
2021-02-12 04:57:04 +08:00
|
|
|
m_value.SetValueType(Value::ValueType::Scalar);
|
2011-04-28 06:04:39 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2011-04-28 06:04:39 +08:00
|
|
|
}
|
|
|
|
|
2021-07-03 02:27:37 +08:00
|
|
|
ValueObjectMemory::~ValueObjectMemory() = default;
|
2011-04-16 08:01:13 +08:00
|
|
|
|
2015-08-25 07:46:31 +08:00
|
|
|
CompilerType ValueObjectMemory::GetCompilerTypeImpl() {
|
2011-04-28 06:04:39 +08:00
|
|
|
if (m_type_sp)
|
2015-08-25 07:46:31 +08:00
|
|
|
return m_type_sp->GetForwardCompilerType();
|
2015-09-24 11:54:50 +08:00
|
|
|
return m_compiler_type;
|
2011-04-16 08:01:13 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
ConstString ValueObjectMemory::GetTypeName() {
|
2011-04-28 06:04:39 +08:00
|
|
|
if (m_type_sp)
|
|
|
|
return m_type_sp->GetName();
|
2020-02-12 16:35:19 +08:00
|
|
|
return m_compiler_type.GetTypeName();
|
2011-04-16 08:01:13 +08:00
|
|
|
}
|
|
|
|
|
Introduce the concept of a "display name" for types
Rationale:
Pretty simply, the idea is that sometimes type names are way too long and contain way too many details for the average developer to care about. For instance, a plain ol' vector of int might be shown as
std::__1::vector<int, std::__1::allocator<....
rather than the much simpler std::vector<int> form, which is what most developers would actually type in their code
Proposed solution:
Introduce a notion of "display name" and a corresponding API GetDisplayTypeName() to return such a crafted for visual representation type name
Obviously, the display name and the fully qualified (or "true") name are not necessarily the same - that's the whole point
LLDB could choose to pick the "display name" as its one true notion of a type name, and if somebody really needs the fully qualified version of it, let them deal with the problem
Or, LLDB could rename what it currently calls the "type name" to be the "display name", and add new APIs for the fully qualified name, making the display name the default choice
The choice that I am making here is that the type name will keep meaning the same, and people who want a type name suited for display will explicitly ask for one
It is the less risky/disruptive choice - and it should eventually make it fairly obvious when someone is asking for the wrong type
Caveats:
- for now, GetDisplayTypeName() == GetTypeName(), there is no logic to produce customized display type names yet.
- while the fully-qualified type name is still the main key to the kingdom of data formatters, if we start showing custom names to people, those should match formatters
llvm-svn: 209072
2014-05-18 03:14:17 +08:00
|
|
|
ConstString ValueObjectMemory::GetDisplayTypeName() {
|
|
|
|
if (m_type_sp)
|
2015-08-25 07:46:31 +08:00
|
|
|
return m_type_sp->GetForwardCompilerType().GetDisplayTypeName();
|
2015-09-24 11:54:50 +08:00
|
|
|
return m_compiler_type.GetDisplayTypeName();
|
Introduce the concept of a "display name" for types
Rationale:
Pretty simply, the idea is that sometimes type names are way too long and contain way too many details for the average developer to care about. For instance, a plain ol' vector of int might be shown as
std::__1::vector<int, std::__1::allocator<....
rather than the much simpler std::vector<int> form, which is what most developers would actually type in their code
Proposed solution:
Introduce a notion of "display name" and a corresponding API GetDisplayTypeName() to return such a crafted for visual representation type name
Obviously, the display name and the fully qualified (or "true") name are not necessarily the same - that's the whole point
LLDB could choose to pick the "display name" as its one true notion of a type name, and if somebody really needs the fully qualified version of it, let them deal with the problem
Or, LLDB could rename what it currently calls the "type name" to be the "display name", and add new APIs for the fully qualified name, making the display name the default choice
The choice that I am making here is that the type name will keep meaning the same, and people who want a type name suited for display will explicitly ask for one
It is the less risky/disruptive choice - and it should eventually make it fairly obvious when someone is asking for the wrong type
Caveats:
- for now, GetDisplayTypeName() == GetTypeName(), there is no logic to produce customized display type names yet.
- while the fully-qualified type name is still the main key to the kingdom of data formatters, if we start showing custom names to people, those should match formatters
llvm-svn: 209072
2014-05-18 03:14:17 +08:00
|
|
|
}
|
|
|
|
|
2015-10-22 03:28:08 +08:00
|
|
|
size_t ValueObjectMemory::CalculateNumChildren(uint32_t max) {
|
2011-04-28 06:04:39 +08:00
|
|
|
if (m_type_sp) {
|
2015-10-22 03:28:08 +08:00
|
|
|
auto child_count = m_type_sp->GetNumChildren(true);
|
|
|
|
return child_count <= max ? child_count : max;
|
2011-04-16 08:01:13 +08:00
|
|
|
}
|
|
|
|
|
2018-11-06 04:49:07 +08:00
|
|
|
ExecutionContext exe_ctx(GetExecutionContextRef());
|
2011-04-28 06:04:39 +08:00
|
|
|
const bool omit_empty_base_classes = true;
|
2018-11-06 04:49:07 +08:00
|
|
|
auto child_count =
|
|
|
|
m_compiler_type.GetNumChildren(omit_empty_base_classes, &exe_ctx);
|
2015-09-24 11:54:50 +08:00
|
|
|
return child_count <= max ? child_count : max;
|
2011-04-16 08:01:13 +08:00
|
|
|
}
|
|
|
|
|
2020-07-25 23:27:21 +08:00
|
|
|
llvm::Optional<uint64_t> ValueObjectMemory::GetByteSize() {
|
2020-07-22 04:53:43 +08:00
|
|
|
ExecutionContext exe_ctx(GetExecutionContextRef());
|
2011-04-16 08:01:13 +08:00
|
|
|
if (m_type_sp)
|
2020-07-25 23:27:21 +08:00
|
|
|
return m_type_sp->GetByteSize(exe_ctx.GetBestExecutionContextScope());
|
|
|
|
return m_compiler_type.GetByteSize(exe_ctx.GetBestExecutionContextScope());
|
2011-04-16 08:01:13 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
lldb::ValueType ValueObjectMemory::GetValueType() const {
|
|
|
|
// RETHINK: Should this be inherited from somewhere?
|
|
|
|
return lldb::eValueTypeVariableGlobal;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool ValueObjectMemory::UpdateValue() {
|
|
|
|
SetValueIsValid(false);
|
|
|
|
m_error.Clear();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2011-04-16 08:01:13 +08:00
|
|
|
ExecutionContext exe_ctx(GetExecutionContextRef());
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2011-04-16 08:01:13 +08:00
|
|
|
Target *target = exe_ctx.GetTargetPtr();
|
2011-09-22 12:58:26 +08:00
|
|
|
if (target) {
|
2011-04-16 08:01:13 +08:00
|
|
|
m_data.SetByteOrder(target->GetArchitecture().GetByteOrder());
|
2011-09-22 12:58:26 +08:00
|
|
|
m_data.SetAddressByteSize(target->GetArchitecture().GetAddressByteSize());
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
2011-04-16 08:01:13 +08:00
|
|
|
Value old_value(m_value);
|
|
|
|
if (m_address.IsValid()) {
|
2013-07-12 06:46:58 +08:00
|
|
|
Value::ValueType value_type = m_value.GetValueType();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2011-04-16 08:01:13 +08:00
|
|
|
switch (value_type) {
|
2021-02-12 04:57:04 +08:00
|
|
|
case Value::ValueType::Invalid:
|
|
|
|
m_error.SetErrorString("Invalid value");
|
|
|
|
return false;
|
|
|
|
case Value::ValueType::Scalar:
|
2018-05-01 00:49:04 +08:00
|
|
|
// The variable value is in the Scalar value inside the m_value. We can
|
|
|
|
// point our m_data right to it.
|
2019-08-09 03:22:32 +08:00
|
|
|
m_error = m_value.GetValueAsData(&exe_ctx, m_data, GetModule().get());
|
2011-04-16 08:01:13 +08:00
|
|
|
break;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2021-02-12 04:57:04 +08:00
|
|
|
case Value::ValueType::FileAddress:
|
|
|
|
case Value::ValueType::LoadAddress:
|
|
|
|
case Value::ValueType::HostAddress:
|
2018-05-01 00:49:04 +08:00
|
|
|
// The DWARF expression result was an address in the inferior process. If
|
|
|
|
// this variable is an aggregate type, we just need the address as the
|
|
|
|
// main value as all child variable objects will rely upon this location
|
|
|
|
// and add an offset and then read their own values as needed. If this
|
|
|
|
// variable is a simple type, we read all data for it into m_data. Make
|
|
|
|
// sure this type has a value before we try and read it
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2011-04-16 08:01:13 +08:00
|
|
|
// If we have a file address, convert it to a load address if we can.
|
2021-02-12 04:57:04 +08:00
|
|
|
if (value_type == Value::ValueType::FileAddress &&
|
2011-09-22 12:58:26 +08:00
|
|
|
exe_ctx.GetProcessPtr()) {
|
|
|
|
lldb::addr_t load_addr = m_address.GetLoadAddress(target);
|
2011-04-16 08:01:13 +08:00
|
|
|
if (load_addr != LLDB_INVALID_ADDRESS) {
|
2021-02-12 04:57:04 +08:00
|
|
|
m_value.SetValueType(Value::ValueType::LoadAddress);
|
2011-04-16 08:01:13 +08:00
|
|
|
m_value.GetScalar() = load_addr;
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
Extend synthetic children to produce synthetic values (as in, those that GetValueAsUnsigned(), GetValueAsCString() would return)
The way to do this is to write a synthetic child provider for your type, and have it vend the (optional) get_value function.
If get_value is defined, and it returns a valid SBValue, that SBValue's value (as in lldb_private::Value) will be used as the synthetic ValueObject's Value
The rationale for doing things this way is twofold:
- there are many possible ways to define a "value" (SBData, a Python number, ...) but SBValue seems general enough as a thing that stores a "value", so we just trade values that way and that keeps our currency trivial
- we could introduce a new level of layering (ValueObjectSyntheticValue), a new kind of formatter (synthetic value producer), but that would complicate the model (can I have a dynamic with no synthetic children but synthetic value? synthetic value with synthetic children but no dynamic?), and I really couldn't see much benefit to be reaped from this added complexity in the matrix
On the other hand, just defining a synthetic child provider with a get_value but returning no actual children is easy enough that it's not a significant road-block to adoption of this feature
Comes with a test case
llvm-svn: 219330
2014-10-09 02:27:36 +08:00
|
|
|
if (!CanProvideValue()) {
|
2018-05-01 00:49:04 +08:00
|
|
|
// this value object represents an aggregate type whose children have
|
|
|
|
// values, but this object does not. So we say we are changed if our
|
|
|
|
// location has changed.
|
2011-04-16 08:01:13 +08:00
|
|
|
SetValueDidChange(value_type != old_value.GetValueType() ||
|
|
|
|
m_value.GetScalar() != old_value.GetScalar());
|
|
|
|
} else {
|
2018-05-01 00:49:04 +08:00
|
|
|
// Copy the Value and set the context to use our Variable so it can
|
|
|
|
// extract read its value into m_data appropriately
|
2011-04-16 08:01:13 +08:00
|
|
|
Value value(m_value);
|
2011-04-28 06:04:39 +08:00
|
|
|
if (m_type_sp)
|
2021-02-12 04:57:04 +08:00
|
|
|
value.SetContext(Value::ContextType::LLDBType, m_type_sp.get());
|
2011-04-28 06:04:39 +08:00
|
|
|
else {
|
2015-09-24 11:54:50 +08:00
|
|
|
value.SetCompilerType(m_compiler_type);
|
2011-04-16 08:01:13 +08:00
|
|
|
}
|
|
|
|
|
2019-08-09 03:22:32 +08:00
|
|
|
m_error = value.GetValueAsData(&exe_ctx, m_data, GetModule().get());
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
break;
|
2011-04-16 08:01:13 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
SetValueIsValid(m_error.Success());
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2011-04-16 08:01:13 +08:00
|
|
|
return m_error.Success();
|
|
|
|
}
|
|
|
|
|
2011-07-07 09:59:51 +08:00
|
|
|
bool ValueObjectMemory::IsInScope() {
|
2012-02-24 09:59:29 +08:00
|
|
|
// FIXME: Maybe try to read the memory address, and if that works, then
|
2011-04-16 08:01:13 +08:00
|
|
|
// we are in scope?
|
2012-02-24 09:59:29 +08:00
|
|
|
return true;
|
2011-07-07 09:59:51 +08:00
|
|
|
}
|
|
|
|
|
2013-07-12 06:46:58 +08:00
|
|
|
lldb::ModuleSP ValueObjectMemory::GetModule() { return m_address.GetModule(); }
|