[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
|
|
|
//===-- ValueObjectVariable.cpp -------------------------------------------===//
|
2010-06-09 00:52:24 +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
|
2010-06-09 00:52:24 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "lldb/Core/ValueObjectVariable.h"
|
|
|
|
|
2018-11-12 07:16:43 +08:00
|
|
|
#include "lldb/Core/Address.h"
|
|
|
|
#include "lldb/Core/AddressRange.h"
|
2021-04-30 11:35:59 +08:00
|
|
|
#include "lldb/Core/Declaration.h"
|
2010-06-09 00:52:24 +08:00
|
|
|
#include "lldb/Core/Module.h"
|
|
|
|
#include "lldb/Core/Value.h"
|
2018-11-12 07:16:43 +08:00
|
|
|
#include "lldb/Expression/DWARFExpression.h"
|
<rdar://problem/11757916>
Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file".
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()
Cleaned up header includes a bit as well.
llvm-svn: 162860
2012-08-30 05:13:06 +08:00
|
|
|
#include "lldb/Symbol/Function.h"
|
2010-06-09 00:52:24 +08:00
|
|
|
#include "lldb/Symbol/ObjectFile.h"
|
|
|
|
#include "lldb/Symbol/SymbolContext.h"
|
2011-07-07 09:59:51 +08:00
|
|
|
#include "lldb/Symbol/SymbolContextScope.h"
|
2010-06-09 00:52:24 +08:00
|
|
|
#include "lldb/Symbol/Type.h"
|
|
|
|
#include "lldb/Symbol/Variable.h"
|
|
|
|
#include "lldb/Target/ExecutionContext.h"
|
|
|
|
#include "lldb/Target/Process.h"
|
|
|
|
#include "lldb/Target/RegisterContext.h"
|
|
|
|
#include "lldb/Target/Target.h"
|
2018-11-12 07:16:43 +08:00
|
|
|
#include "lldb/Utility/DataExtractor.h"
|
2018-08-07 19:07:21 +08:00
|
|
|
#include "lldb/Utility/RegisterValue.h"
|
2018-11-12 07:16:43 +08:00
|
|
|
#include "lldb/Utility/Scalar.h"
|
|
|
|
#include "lldb/Utility/Status.h"
|
|
|
|
#include "lldb/lldb-private-enumerations.h"
|
|
|
|
#include "lldb/lldb-types.h"
|
2017-04-07 05:28:29 +08:00
|
|
|
|
2018-11-12 07:16:43 +08:00
|
|
|
#include "llvm/ADT/StringRef.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>
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2017-04-07 05:28:29 +08:00
|
|
|
namespace lldb_private {
|
|
|
|
class ExecutionContextScope;
|
|
|
|
}
|
|
|
|
namespace lldb_private {
|
|
|
|
class StackFrame;
|
|
|
|
}
|
|
|
|
namespace lldb_private {
|
|
|
|
struct RegisterInfo;
|
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
using namespace lldb_private;
|
|
|
|
|
2011-04-23 07:53:53 +08:00
|
|
|
lldb::ValueObjectSP
|
|
|
|
ValueObjectVariable::Create(ExecutionContextScope *exe_scope,
|
|
|
|
const lldb::VariableSP &var_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 ValueObjectVariable(exe_scope, *manager_sp, var_sp))->GetSP();
|
2011-04-23 07:53:53 +08:00
|
|
|
}
|
|
|
|
|
2011-03-31 08:19:25 +08:00
|
|
|
ValueObjectVariable::ValueObjectVariable(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,
|
2011-03-31 08:19:25 +08:00
|
|
|
const lldb::VariableSP &var_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_variable_sp(var_sp) {
|
2010-06-09 00:52:24 +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_variable_sp.get() != nullptr);
|
2010-06-09 00:52:24 +08:00
|
|
|
m_name = var_sp->GetName();
|
|
|
|
}
|
|
|
|
|
2021-07-03 02:27:37 +08:00
|
|
|
ValueObjectVariable::~ValueObjectVariable() = default;
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2015-08-25 07:46:31 +08:00
|
|
|
CompilerType ValueObjectVariable::GetCompilerTypeImpl() {
|
2010-06-09 00:52:24 +08:00
|
|
|
Type *var_type = m_variable_sp->GetType();
|
2018-11-09 06:47:40 +08:00
|
|
|
if (var_type)
|
|
|
|
return var_type->GetForwardCompilerType();
|
|
|
|
return CompilerType();
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
ConstString ValueObjectVariable::GetTypeName() {
|
|
|
|
Type *var_type = m_variable_sp->GetType();
|
|
|
|
if (var_type)
|
|
|
|
return var_type->GetName();
|
2012-03-27 07:03:23 +08:00
|
|
|
return ConstString();
|
|
|
|
}
|
|
|
|
|
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 ValueObjectVariable::GetDisplayTypeName() {
|
|
|
|
Type *var_type = m_variable_sp->GetType();
|
|
|
|
if (var_type)
|
2015-08-25 07:46:31 +08:00
|
|
|
return var_type->GetForwardCompilerType().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
|
|
|
return ConstString();
|
|
|
|
}
|
|
|
|
|
2012-03-27 07:03:23 +08:00
|
|
|
ConstString ValueObjectVariable::GetQualifiedTypeName() {
|
|
|
|
Type *var_type = m_variable_sp->GetType();
|
|
|
|
if (var_type)
|
|
|
|
return var_type->GetQualifiedName();
|
|
|
|
return ConstString();
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2015-10-22 03:28:08 +08:00
|
|
|
size_t ValueObjectVariable::CalculateNumChildren(uint32_t max) {
|
2015-08-25 07:46:31 +08:00
|
|
|
CompilerType type(GetCompilerType());
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-02-23 07:57:45 +08:00
|
|
|
if (!type.IsValid())
|
|
|
|
return 0;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2018-11-06 04:49:07 +08:00
|
|
|
ExecutionContext exe_ctx(GetExecutionContextRef());
|
2012-02-23 07:57:45 +08:00
|
|
|
const bool omit_empty_base_classes = true;
|
2018-11-06 04:49:07 +08:00
|
|
|
auto child_count = type.GetNumChildren(omit_empty_base_classes, &exe_ctx);
|
2015-10-22 03:28:08 +08:00
|
|
|
return child_count <= max ? child_count : max;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2020-07-25 23:27:21 +08:00
|
|
|
llvm::Optional<uint64_t> ValueObjectVariable::GetByteSize() {
|
2015-01-28 09:09:45 +08:00
|
|
|
ExecutionContext exe_ctx(GetExecutionContextRef());
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2015-08-25 07:46:31 +08:00
|
|
|
CompilerType type(GetCompilerType());
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2012-02-23 07:57:45 +08:00
|
|
|
if (!type.IsValid())
|
2020-07-25 23:27:21 +08:00
|
|
|
return {};
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2020-07-25 23:27:21 +08:00
|
|
|
return type.GetByteSize(exe_ctx.GetBestExecutionContextScope());
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
lldb::ValueType ValueObjectVariable::GetValueType() const {
|
|
|
|
if (m_variable_sp)
|
|
|
|
return m_variable_sp->GetScope();
|
|
|
|
return lldb::eValueTypeInvalid;
|
|
|
|
}
|
|
|
|
|
2011-03-31 08:19:25 +08:00
|
|
|
bool ValueObjectVariable::UpdateValue() {
|
2013-05-01 04:45:04 +08:00
|
|
|
SetValueIsValid(false);
|
2011-09-22 12:58:26 +08:00
|
|
|
m_error.Clear();
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2011-05-30 08:49:24 +08:00
|
|
|
Variable *variable = m_variable_sp.get();
|
2014-12-19 09:28:42 +08:00
|
|
|
DWARFExpression &expr = variable->LocationExpression();
|
2011-05-30 08:49:24 +08:00
|
|
|
|
2013-07-12 06:46:58 +08:00
|
|
|
if (variable->GetLocationIsConstantValueData()) {
|
2011-05-30 08:49:24 +08:00
|
|
|
// expr doesn't contain DWARF bytes, it contains the constant variable
|
|
|
|
// value bytes themselves...
|
2020-08-25 05:38:55 +08:00
|
|
|
if (expr.GetExpressionData(m_data)) {
|
|
|
|
if (m_data.GetDataStart() && m_data.GetByteSize())
|
|
|
|
m_value.SetBytes(m_data.GetDataStart(), m_data.GetByteSize());
|
2021-02-12 04:57:04 +08:00
|
|
|
m_value.SetContext(Value::ContextType::Variable, variable);
|
2020-08-25 05:38:55 +08:00
|
|
|
}
|
2014-12-19 09:28:42 +08:00
|
|
|
else
|
2011-05-30 08:49:24 +08:00
|
|
|
m_error.SetErrorString("empty constant data");
|
|
|
|
// constant bytes can't be edited - sorry
|
2021-02-12 04:57:04 +08:00
|
|
|
m_resolved_value.SetContext(Value::ContextType::Invalid, nullptr);
|
2010-09-13 10:37:44 +08:00
|
|
|
} else {
|
2011-09-22 12:58:26 +08:00
|
|
|
lldb::addr_t loclist_base_load_addr = LLDB_INVALID_ADDRESS;
|
2011-05-30 08:49:24 +08:00
|
|
|
ExecutionContext exe_ctx(GetExecutionContextRef());
|
2010-09-13 10:37:44 +08:00
|
|
|
|
2011-05-30 08:49:24 +08:00
|
|
|
Target *target = exe_ctx.GetTargetPtr();
|
|
|
|
if (target) {
|
|
|
|
m_data.SetByteOrder(target->GetArchitecture().GetByteOrder());
|
|
|
|
m_data.SetAddressByteSize(target->GetArchitecture().GetAddressByteSize());
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
2011-05-30 08:49:24 +08:00
|
|
|
if (expr.IsLocationList()) {
|
|
|
|
SymbolContext sc;
|
|
|
|
variable->CalculateSymbolContext(&sc);
|
|
|
|
if (sc.function)
|
|
|
|
loclist_base_load_addr =
|
|
|
|
sc.function->GetAddressRange().GetBaseAddress().GetLoadAddress(
|
2016-09-07 04:57:50 +08:00
|
|
|
target);
|
|
|
|
}
|
2011-05-30 08:49:24 +08:00
|
|
|
Value old_value(m_value);
|
2017-08-16 19:45:10 +08:00
|
|
|
if (expr.Evaluate(&exe_ctx, nullptr, loclist_base_load_addr, nullptr,
|
|
|
|
nullptr, m_value, &m_error)) {
|
2013-05-01 04:45:04 +08:00
|
|
|
m_resolved_value = m_value;
|
2021-02-12 04:57:04 +08:00
|
|
|
m_value.SetContext(Value::ContextType::Variable, variable);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2015-09-24 11:54:50 +08:00
|
|
|
CompilerType compiler_type = GetCompilerType();
|
|
|
|
if (compiler_type.IsValid())
|
|
|
|
m_value.SetCompilerType(compiler_type);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2011-05-30 08:49:24 +08:00
|
|
|
Value::ValueType value_type = m_value.GetValueType();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
[lldb/Value] Avoid reading more data than the host has available
Value::GetValueByteSize() reports the size of a Value as the size of its
underlying CompilerType. However, a host buffer that backs a Value may
be smaller than GetValueByteSize().
This situation arises when the host is only able to partially evaluate a
Value, e.g. because the expression contains DW_OP_piece.
The cleanest fix I've found to this problem is Greg's suggestion, which
is to resize the Value if (after evaluating an expression) it's found to
be too small. I've tried several alternatives which all (in one way or
the other) tried to teach the Value/ValueObjectChild system not to read
past the end of a host buffer, but this was flaky and impractical as it
isn't easy to figure out the host buffer's size (Value::GetScalar() can
point to somewhere /inside/ a host buffer, but you need to walk up the
ValueObject hierarchy to try and find its size).
This fixes an ASan error in lldb seen when debugging a clang binary.
I've added a regression test in test/functionalities/optimized_code. The
point of that test is not specifically to check that DW_OP_piece is
handled a particular way, but rather to check that lldb doesn't crash on
an input that it used to crash on.
Testing: check-lldb, and running the added tests using a sanitized lldb
--
Thanks to Jim for pointing out that an earlier version of this patch,
which simply changed the definition of Value::GetValueByteSize(), would
interact poorly with the ValueObject machinery.
Thanks also to Pavel who suggested a neat way to test this change
(which, incidentally, caught another ASan issue still present in the
original version of this patch).
rdar://58665925
Differential Revision: https://reviews.llvm.org/D73148
2020-01-22 08:01:16 +08:00
|
|
|
// The size of the buffer within m_value can be less than the size
|
|
|
|
// prescribed by its type. E.g. this can happen when an expression only
|
|
|
|
// partially describes an object (say, because it contains DW_OP_piece).
|
|
|
|
//
|
|
|
|
// In this case, grow m_value to the expected size. An alternative way to
|
|
|
|
// handle this is to teach Value::GetValueAsData() and ValueObjectChild
|
|
|
|
// not to read past the end of a host buffer, but this gets impractically
|
|
|
|
// complicated as a Value's host buffer may be shared with a distant
|
|
|
|
// ancestor or sibling in the ValueObject hierarchy.
|
|
|
|
//
|
|
|
|
// FIXME: When we grow m_value, we should represent the added bits as
|
|
|
|
// undefined somehow instead of as 0's.
|
2021-02-12 04:57:04 +08:00
|
|
|
if (value_type == Value::ValueType::HostAddress &&
|
[lldb/Value] Avoid reading more data than the host has available
Value::GetValueByteSize() reports the size of a Value as the size of its
underlying CompilerType. However, a host buffer that backs a Value may
be smaller than GetValueByteSize().
This situation arises when the host is only able to partially evaluate a
Value, e.g. because the expression contains DW_OP_piece.
The cleanest fix I've found to this problem is Greg's suggestion, which
is to resize the Value if (after evaluating an expression) it's found to
be too small. I've tried several alternatives which all (in one way or
the other) tried to teach the Value/ValueObjectChild system not to read
past the end of a host buffer, but this was flaky and impractical as it
isn't easy to figure out the host buffer's size (Value::GetScalar() can
point to somewhere /inside/ a host buffer, but you need to walk up the
ValueObject hierarchy to try and find its size).
This fixes an ASan error in lldb seen when debugging a clang binary.
I've added a regression test in test/functionalities/optimized_code. The
point of that test is not specifically to check that DW_OP_piece is
handled a particular way, but rather to check that lldb doesn't crash on
an input that it used to crash on.
Testing: check-lldb, and running the added tests using a sanitized lldb
--
Thanks to Jim for pointing out that an earlier version of this patch,
which simply changed the definition of Value::GetValueByteSize(), would
interact poorly with the ValueObject machinery.
Thanks also to Pavel who suggested a neat way to test this change
(which, incidentally, caught another ASan issue still present in the
original version of this patch).
rdar://58665925
Differential Revision: https://reviews.llvm.org/D73148
2020-01-22 08:01:16 +08:00
|
|
|
compiler_type.IsValid()) {
|
|
|
|
if (size_t value_buf_size = m_value.GetBuffer().GetByteSize()) {
|
|
|
|
size_t value_size = m_value.GetValueByteSize(&m_error, &exe_ctx);
|
|
|
|
if (m_error.Success() && value_buf_size < value_size)
|
|
|
|
m_value.ResizeData(value_size);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-12-19 09:28:42 +08:00
|
|
|
Process *process = exe_ctx.GetProcessPtr();
|
|
|
|
const bool process_is_alive = process && process->IsAlive();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
Redesign of the interaction between Python and frozen objects:
- introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from
a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored
in frozen objects ; now such reads transparently move from host to target as required
- as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also
removed code that enabled to recognize an expression result VO as such
- introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO
representing a T* or T[], and doing dereferences transparently
in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData
- as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it
en lieu of doing the raw read itself
- introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers,
this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory)
in public layer this returns an SBData, just like GetPointeeData()
- introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData
the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any
of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values
- added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing
Solved a bug where global pointers to global variables were not dereferenced correctly for display
New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128
Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command
Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type
of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file
addresses that generate file address children UNLESS we have a live process)
Updated help text for summary-string
Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers
Edited the syntax and help for some commands to have proper argument types
llvm-svn: 139160
2011-09-07 03:20:51 +08:00
|
|
|
switch (value_type) {
|
2021-02-12 04:57:04 +08:00
|
|
|
case Value::ValueType::Invalid:
|
|
|
|
m_error.SetErrorString("invalid value");
|
|
|
|
break;
|
|
|
|
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.
|
2013-07-12 06:46:58 +08:00
|
|
|
m_error =
|
2019-08-09 03:22:32 +08:00
|
|
|
m_value.GetValueAsData(&exe_ctx, m_data, GetModule().get());
|
2016-09-07 04:57:50 +08:00
|
|
|
break;
|
|
|
|
|
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
|
|
|
|
2014-11-05 05:28:50 +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 && process_is_alive)
|
2018-05-04 07:32:47 +08:00
|
|
|
m_value.ConvertToLoadAddress(GetModule().get(), target);
|
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.
|
2013-05-01 04:45:04 +08:00
|
|
|
SetValueDidChange(value_type != old_value.GetValueType() ||
|
|
|
|
m_value.GetScalar() != old_value.GetScalar());
|
2016-09-07 04:57:50 +08:00
|
|
|
} 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-05-30 08:49:24 +08:00
|
|
|
Value value(m_value);
|
2021-02-12 04:57:04 +08:00
|
|
|
value.SetContext(Value::ContextType::Variable, variable);
|
2013-07-12 06:46:58 +08:00
|
|
|
m_error =
|
2019-08-09 03:22:32 +08:00
|
|
|
value.GetValueAsData(&exe_ctx, m_data, GetModule().get());
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2011-05-30 08:49:24 +08:00
|
|
|
SetValueDidChange(value_type != old_value.GetValueType() ||
|
|
|
|
m_value.GetScalar() != old_value.GetScalar());
|
2013-05-01 04:45:04 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2011-05-30 08:49:24 +08:00
|
|
|
SetValueIsValid(m_error.Success());
|
2016-09-07 04:57:50 +08:00
|
|
|
} else {
|
2013-05-01 04:45:04 +08:00
|
|
|
// could not find location, won't allow editing
|
2021-02-12 04:57:04 +08:00
|
|
|
m_resolved_value.SetContext(Value::ContextType::Invalid, nullptr);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2020-07-11 02:10:56 +08:00
|
|
|
|
2011-03-31 08:19:25 +08:00
|
|
|
return m_error.Success();
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2020-07-11 02:10:56 +08:00
|
|
|
void ValueObjectVariable::DoUpdateChildrenAddressType(ValueObject &valobj) {
|
|
|
|
Value::ValueType value_type = valobj.GetValue().GetValueType();
|
|
|
|
ExecutionContext exe_ctx(GetExecutionContextRef());
|
|
|
|
Process *process = exe_ctx.GetProcessPtr();
|
|
|
|
const bool process_is_alive = process && process->IsAlive();
|
|
|
|
const uint32_t type_info = valobj.GetCompilerType().GetTypeInfo();
|
|
|
|
const bool is_pointer_or_ref =
|
|
|
|
(type_info & (lldb::eTypeIsPointer | lldb::eTypeIsReference)) != 0;
|
|
|
|
|
|
|
|
switch (value_type) {
|
2021-02-12 04:57:04 +08:00
|
|
|
case Value::ValueType::Invalid:
|
|
|
|
break;
|
|
|
|
case Value::ValueType::FileAddress:
|
2020-07-11 02:10:56 +08:00
|
|
|
// If this type is a pointer, then its children will be considered load
|
|
|
|
// addresses if the pointer or reference is dereferenced, but only if
|
|
|
|
// the process is alive.
|
|
|
|
//
|
|
|
|
// There could be global variables like in the following code:
|
|
|
|
// struct LinkedListNode { Foo* foo; LinkedListNode* next; };
|
|
|
|
// Foo g_foo1;
|
|
|
|
// Foo g_foo2;
|
|
|
|
// LinkedListNode g_second_node = { &g_foo2, NULL };
|
|
|
|
// LinkedListNode g_first_node = { &g_foo1, &g_second_node };
|
|
|
|
//
|
|
|
|
// When we aren't running, we should be able to look at these variables
|
|
|
|
// using the "target variable" command. Children of the "g_first_node"
|
|
|
|
// always will be of the same address type as the parent. But children
|
|
|
|
// of the "next" member of LinkedListNode will become load addresses if
|
|
|
|
// we have a live process, or remain a file address if it was a file
|
|
|
|
// address.
|
|
|
|
if (process_is_alive && is_pointer_or_ref)
|
|
|
|
valobj.SetAddressTypeOfChildren(eAddressTypeLoad);
|
|
|
|
else
|
|
|
|
valobj.SetAddressTypeOfChildren(eAddressTypeFile);
|
|
|
|
break;
|
2021-02-12 04:57:04 +08:00
|
|
|
case Value::ValueType::HostAddress:
|
2020-07-11 02:10:56 +08:00
|
|
|
// Same as above for load addresses, except children of pointer or refs
|
|
|
|
// are always load addresses. Host addresses are used to store freeze
|
|
|
|
// dried variables. If this type is a struct, the entire struct
|
|
|
|
// contents will be copied into the heap of the
|
|
|
|
// LLDB process, but we do not currently follow any pointers.
|
|
|
|
if (is_pointer_or_ref)
|
|
|
|
valobj.SetAddressTypeOfChildren(eAddressTypeLoad);
|
|
|
|
else
|
|
|
|
valobj.SetAddressTypeOfChildren(eAddressTypeHost);
|
|
|
|
break;
|
2021-02-12 04:57:04 +08:00
|
|
|
case Value::ValueType::LoadAddress:
|
|
|
|
case Value::ValueType::Scalar:
|
2020-07-11 02:10:56 +08:00
|
|
|
valobj.SetAddressTypeOfChildren(eAddressTypeLoad);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-31 08:19:25 +08:00
|
|
|
bool ValueObjectVariable::IsInScope() {
|
2012-02-17 15:49:44 +08:00
|
|
|
const ExecutionContextRef &exe_ctx_ref = GetExecutionContextRef();
|
|
|
|
if (exe_ctx_ref.HasFrameRef()) {
|
|
|
|
ExecutionContext exe_ctx(exe_ctx_ref);
|
2013-11-04 17:33:30 +08:00
|
|
|
StackFrame *frame = exe_ctx.GetFramePtr();
|
2012-02-17 15:49:44 +08:00
|
|
|
if (frame) {
|
|
|
|
return m_variable_sp->IsInScope(frame);
|
|
|
|
} else {
|
2018-05-01 00:49:04 +08:00
|
|
|
// This ValueObject had a frame at one time, but now we can't locate it,
|
|
|
|
// so return false since we probably aren't in scope.
|
2012-02-17 15:49:44 +08:00
|
|
|
return false;
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2018-05-01 00:49:04 +08:00
|
|
|
// We have a variable that wasn't tied to a frame, which means it is a global
|
|
|
|
// and is always in scope.
|
2012-02-17 15:49:44 +08:00
|
|
|
return true;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2011-07-07 09:59:51 +08:00
|
|
|
lldb::ModuleSP ValueObjectVariable::GetModule() {
|
|
|
|
if (m_variable_sp) {
|
|
|
|
SymbolContextScope *sc_scope = m_variable_sp->GetSymbolContextScope();
|
|
|
|
if (sc_scope) {
|
2012-02-24 09:59:29 +08:00
|
|
|
return sc_scope->CalculateSymbolContextModule();
|
2011-07-07 09:59:51 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2012-02-24 09:59:29 +08:00
|
|
|
return lldb::ModuleSP();
|
2011-07-07 09:59:51 +08:00
|
|
|
}
|
|
|
|
|
Redesign of the interaction between Python and frozen objects:
- introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from
a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored
in frozen objects ; now such reads transparently move from host to target as required
- as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also
removed code that enabled to recognize an expression result VO as such
- introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO
representing a T* or T[], and doing dereferences transparently
in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData
- as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it
en lieu of doing the raw read itself
- introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers,
this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory)
in public layer this returns an SBData, just like GetPointeeData()
- introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData
the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any
of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values
- added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing
Solved a bug where global pointers to global variables were not dereferenced correctly for display
New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128
Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command
Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type
of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file
addresses that generate file address children UNLESS we have a live process)
Updated help text for summary-string
Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers
Edited the syntax and help for some commands to have proper argument types
llvm-svn: 139160
2011-09-07 03:20:51 +08:00
|
|
|
SymbolContextScope *ValueObjectVariable::GetSymbolContextScope() {
|
|
|
|
if (m_variable_sp)
|
|
|
|
return m_variable_sp->GetSymbolContextScope();
|
[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
|
|
|
return nullptr;
|
Redesign of the interaction between Python and frozen objects:
- introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from
a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored
in frozen objects ; now such reads transparently move from host to target as required
- as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also
removed code that enabled to recognize an expression result VO as such
- introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO
representing a T* or T[], and doing dereferences transparently
in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData
- as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it
en lieu of doing the raw read itself
- introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers,
this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory)
in public layer this returns an SBData, just like GetPointeeData()
- introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData
the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any
of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values
- added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing
Solved a bug where global pointers to global variables were not dereferenced correctly for display
New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128
Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command
Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type
of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file
addresses that generate file address children UNLESS we have a live process)
Updated help text for summary-string
Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers
Edited the syntax and help for some commands to have proper argument types
llvm-svn: 139160
2011-09-07 03:20:51 +08:00
|
|
|
}
|
2012-02-04 10:27:34 +08:00
|
|
|
|
|
|
|
bool ValueObjectVariable::GetDeclaration(Declaration &decl) {
|
|
|
|
if (m_variable_sp) {
|
|
|
|
decl = m_variable_sp->GetDeclaration();
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
2013-05-01 04:45:04 +08:00
|
|
|
|
|
|
|
const char *ValueObjectVariable::GetLocationAsCString() {
|
2021-02-12 04:57:04 +08:00
|
|
|
if (m_resolved_value.GetContextType() == Value::ContextType::RegisterInfo)
|
2013-05-04 07:28:47 +08:00
|
|
|
return GetLocationAsCStringImpl(m_resolved_value, m_data);
|
|
|
|
else
|
|
|
|
return ValueObject::GetLocationAsCString();
|
2013-05-01 04:45:04 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool ValueObjectVariable::SetValueFromCString(const char *value_str,
|
2017-05-12 12:51:55 +08:00
|
|
|
Status &error) {
|
2014-01-18 09:13:50 +08:00
|
|
|
if (!UpdateValueIfNeeded()) {
|
|
|
|
error.SetErrorString("unable to update value before writing");
|
2013-05-01 04:45:04 +08:00
|
|
|
return false;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
2021-02-12 04:57:04 +08:00
|
|
|
if (m_resolved_value.GetContextType() == Value::ContextType::RegisterInfo) {
|
2013-05-01 04:45:04 +08:00
|
|
|
RegisterInfo *reg_info = m_resolved_value.GetRegisterInfo();
|
|
|
|
ExecutionContext exe_ctx(GetExecutionContextRef());
|
|
|
|
RegisterContext *reg_ctx = exe_ctx.GetRegisterContext();
|
|
|
|
RegisterValue reg_value;
|
|
|
|
if (!reg_info || !reg_ctx) {
|
|
|
|
error.SetErrorString("unable to retrieve register info");
|
2014-01-18 09:13:50 +08:00
|
|
|
return false;
|
|
|
|
}
|
2016-11-18 07:47:31 +08:00
|
|
|
error = reg_value.SetValueFromString(reg_info, llvm::StringRef(value_str));
|
2013-05-01 04:45:04 +08:00
|
|
|
if (error.Fail())
|
|
|
|
return false;
|
|
|
|
if (reg_ctx->WriteRegister(reg_info, reg_value)) {
|
|
|
|
SetNeedsUpdate();
|
|
|
|
return true;
|
|
|
|
} else {
|
|
|
|
error.SetErrorString("unable to write back to register");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
} else
|
|
|
|
return ValueObject::SetValueFromCString(value_str, error);
|
|
|
|
}
|
|
|
|
|
2017-05-12 12:51:55 +08:00
|
|
|
bool ValueObjectVariable::SetData(DataExtractor &data, Status &error) {
|
2014-01-18 09:13:50 +08:00
|
|
|
if (!UpdateValueIfNeeded()) {
|
|
|
|
error.SetErrorString("unable to update value before writing");
|
2013-05-01 04:45:04 +08:00
|
|
|
return false;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
2021-02-12 04:57:04 +08:00
|
|
|
if (m_resolved_value.GetContextType() == Value::ContextType::RegisterInfo) {
|
2013-05-01 04:45:04 +08:00
|
|
|
RegisterInfo *reg_info = m_resolved_value.GetRegisterInfo();
|
|
|
|
ExecutionContext exe_ctx(GetExecutionContextRef());
|
|
|
|
RegisterContext *reg_ctx = exe_ctx.GetRegisterContext();
|
|
|
|
RegisterValue reg_value;
|
|
|
|
if (!reg_info || !reg_ctx) {
|
|
|
|
error.SetErrorString("unable to retrieve register info");
|
2014-01-18 09:13:50 +08:00
|
|
|
return false;
|
|
|
|
}
|
2013-05-01 04:45:04 +08:00
|
|
|
error = reg_value.SetValueFromData(reg_info, data, 0, true);
|
|
|
|
if (error.Fail())
|
|
|
|
return false;
|
|
|
|
if (reg_ctx->WriteRegister(reg_info, reg_value)) {
|
|
|
|
SetNeedsUpdate();
|
|
|
|
return true;
|
|
|
|
} else {
|
|
|
|
error.SetErrorString("unable to write back to register");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
} else
|
|
|
|
return ValueObject::SetData(data, error);
|
|
|
|
}
|