[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
|
|
|
//===-- ValueObjectChild.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/ValueObjectChild.h"
|
|
|
|
|
2018-11-12 07:16:43 +08:00
|
|
|
#include "lldb/Core/Value.h"
|
2015-08-12 06:53:00 +08:00
|
|
|
#include "lldb/Symbol/CompilerType.h"
|
2010-06-09 00:52:24 +08:00
|
|
|
#include "lldb/Target/ExecutionContext.h"
|
|
|
|
#include "lldb/Target/Process.h"
|
2018-11-12 07:16:43 +08:00
|
|
|
#include "lldb/Utility/Flags.h"
|
|
|
|
#include "lldb/Utility/Scalar.h"
|
|
|
|
#include "lldb/Utility/Status.h"
|
|
|
|
#include "lldb/lldb-forward.h"
|
2017-04-07 05:28:29 +08:00
|
|
|
|
2018-11-12 07:16:43 +08:00
|
|
|
#include <functional>
|
|
|
|
#include <memory>
|
|
|
|
#include <vector>
|
2017-04-07 05:28:29 +08:00
|
|
|
|
2018-11-12 07:16:43 +08:00
|
|
|
#include <stdio.h>
|
|
|
|
#include <string.h>
|
2010-06-09 00:52:24 +08:00
|
|
|
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
|
|
|
ValueObjectChild::ValueObjectChild(
|
2015-09-24 11:54:50 +08:00
|
|
|
ValueObject &parent, const CompilerType &compiler_type,
|
2019-03-07 05:22:25 +08:00
|
|
|
ConstString name, uint64_t byte_size, int32_t byte_offset,
|
2010-10-15 06:52:14 +08:00
|
|
|
uint32_t bitfield_bit_size, uint32_t bitfield_bit_offset,
|
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
|
|
|
bool is_base_class, bool is_deref_of_parent,
|
2015-11-10 03:27:34 +08:00
|
|
|
AddressType child_ptr_or_ref_addr_type, uint64_t language_flags)
|
2015-09-24 11:54:50 +08:00
|
|
|
: ValueObject(parent), m_compiler_type(compiler_type),
|
2010-06-09 00:52:24 +08:00
|
|
|
m_byte_size(byte_size), m_byte_offset(byte_offset),
|
|
|
|
m_bitfield_bit_size(bitfield_bit_size),
|
2010-10-15 06:52:14 +08:00
|
|
|
m_bitfield_bit_offset(bitfield_bit_offset),
|
2015-07-28 09:45:23 +08:00
|
|
|
m_is_base_class(is_base_class), m_is_deref_of_parent(is_deref_of_parent),
|
|
|
|
m_can_update_with_invalid_exe_ctx() {
|
2010-06-09 00:52:24 +08:00
|
|
|
m_name = name;
|
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
|
|
|
SetAddressTypeOfChildren(child_ptr_or_ref_addr_type);
|
2015-11-10 03:27:34 +08:00
|
|
|
SetLanguageFlags(language_flags);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
ValueObjectChild::~ValueObjectChild() {}
|
|
|
|
|
|
|
|
lldb::ValueType ValueObjectChild::GetValueType() const {
|
|
|
|
return m_parent->GetValueType();
|
|
|
|
}
|
|
|
|
|
2015-10-22 03:28:08 +08:00
|
|
|
size_t ValueObjectChild::CalculateNumChildren(uint32_t max) {
|
2018-11-06 04:49:07 +08:00
|
|
|
ExecutionContext exe_ctx(GetExecutionContextRef());
|
|
|
|
auto children_count = GetCompilerType().GetNumChildren(true, &exe_ctx);
|
2015-10-22 03:28:08 +08:00
|
|
|
return children_count <= max ? children_count : max;
|
2010-06-09 00:52:24 +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
|
|
|
static void AdjustForBitfieldness(ConstString &name,
|
|
|
|
uint8_t bitfield_bit_size) {
|
2020-07-27 20:05:23 +08:00
|
|
|
if (name && bitfield_bit_size)
|
|
|
|
name.SetString(llvm::formatv("{0}:{1}", name, bitfield_bit_size).str());
|
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
|
|
|
}
|
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
ConstString ValueObjectChild::GetTypeName() {
|
|
|
|
if (m_type_name.IsEmpty()) {
|
2020-02-12 16:35:19 +08:00
|
|
|
m_type_name = GetCompilerType().GetTypeName();
|
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
|
|
|
AdjustForBitfieldness(m_type_name, m_bitfield_bit_size);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
return m_type_name;
|
|
|
|
}
|
|
|
|
|
2012-03-27 07:03:23 +08:00
|
|
|
ConstString ValueObjectChild::GetQualifiedTypeName() {
|
2020-02-12 16:35:19 +08:00
|
|
|
ConstString qualified_name = GetCompilerType().GetTypeName();
|
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
|
|
|
AdjustForBitfieldness(qualified_name, m_bitfield_bit_size);
|
2012-03-27 07:03:23 +08:00
|
|
|
return qualified_name;
|
|
|
|
}
|
|
|
|
|
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 ValueObjectChild::GetDisplayTypeName() {
|
2015-08-25 07:46:31 +08:00
|
|
|
ConstString display_name = GetCompilerType().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
|
|
|
AdjustForBitfieldness(display_name, m_bitfield_bit_size);
|
|
|
|
return display_name;
|
|
|
|
}
|
|
|
|
|
2015-05-20 02:53:13 +08:00
|
|
|
LazyBool ValueObjectChild::CanUpdateWithInvalidExecutionContext() {
|
2015-07-28 09:45:23 +08:00
|
|
|
if (m_can_update_with_invalid_exe_ctx.hasValue())
|
|
|
|
return m_can_update_with_invalid_exe_ctx.getValue();
|
2015-07-24 17:52:25 +08:00
|
|
|
if (m_parent) {
|
2015-07-28 09:45:23 +08:00
|
|
|
ValueObject *opinionated_parent =
|
|
|
|
m_parent->FollowParentChain([](ValueObject *valobj) -> bool {
|
|
|
|
return (valobj->CanUpdateWithInvalidExecutionContext() ==
|
|
|
|
eLazyBoolCalculate);
|
|
|
|
});
|
|
|
|
if (opinionated_parent)
|
|
|
|
return (m_can_update_with_invalid_exe_ctx =
|
|
|
|
opinionated_parent->CanUpdateWithInvalidExecutionContext())
|
|
|
|
.getValue();
|
|
|
|
}
|
|
|
|
return (m_can_update_with_invalid_exe_ctx =
|
|
|
|
this->ValueObject::CanUpdateWithInvalidExecutionContext())
|
|
|
|
.getValue();
|
2015-05-20 02:53:13 +08:00
|
|
|
}
|
|
|
|
|
2011-03-31 08:19:25 +08:00
|
|
|
bool ValueObjectChild::UpdateValue() {
|
2010-06-09 00:52:24 +08:00
|
|
|
m_error.Clear();
|
|
|
|
SetValueIsValid(false);
|
|
|
|
ValueObject *parent = m_parent;
|
|
|
|
if (parent) {
|
2011-08-03 01:27:39 +08:00
|
|
|
if (parent->UpdateValueIfNeeded(false)) {
|
2015-08-25 07:46:31 +08:00
|
|
|
m_value.SetCompilerType(GetCompilerType());
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2015-11-10 07:59:53 +08:00
|
|
|
CompilerType parent_type(parent->GetCompilerType());
|
2010-06-09 00:52:24 +08:00
|
|
|
// Copy the parent scalar value and the scalar value type
|
|
|
|
m_value.GetScalar() = parent->GetValue().GetScalar();
|
|
|
|
Value::ValueType value_type = parent->GetValue().GetValueType();
|
|
|
|
m_value.SetValueType(value_type);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2015-11-10 07:59:53 +08:00
|
|
|
Flags parent_type_flags(parent_type.GetTypeInfo());
|
|
|
|
const bool is_instance_ptr_base =
|
2018-12-15 08:15:33 +08:00
|
|
|
((m_is_base_class) &&
|
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
|
|
|
(parent_type_flags.AnySet(lldb::eTypeInstanceIsPointer)));
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2010-11-02 09:50:16 +08:00
|
|
|
if (parent->GetCompilerType().ShouldTreatScalarValueAsAddress()) {
|
|
|
|
lldb::addr_t addr = parent->GetPointerValue();
|
|
|
|
m_value.GetScalar() = addr;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2010-11-02 09:50:16 +08:00
|
|
|
if (addr == LLDB_INVALID_ADDRESS) {
|
|
|
|
m_error.SetErrorString("parent address is invalid.");
|
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
|
|
|
} else if (addr == 0) {
|
|
|
|
m_error.SetErrorString("parent is NULL");
|
2015-11-10 07:59:53 +08:00
|
|
|
} else {
|
|
|
|
m_value.GetScalar() += m_byte_offset;
|
|
|
|
AddressType addr_type = parent->GetAddressTypeOfChildren();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2015-11-10 07:59:53 +08:00
|
|
|
switch (addr_type) {
|
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
|
|
|
case eAddressTypeFile: {
|
2015-11-10 07:59:53 +08:00
|
|
|
lldb::ProcessSP process_sp(GetProcessSP());
|
2018-12-15 08:15:33 +08:00
|
|
|
if (process_sp && process_sp->IsAlive())
|
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
|
|
|
m_value.SetValueType(Value::eValueTypeLoadAddress);
|
2010-06-09 00:52:24 +08:00
|
|
|
else
|
2015-11-10 07:59:53 +08:00
|
|
|
m_value.SetValueType(Value::eValueTypeFileAddress);
|
2016-09-07 04:57:50 +08:00
|
|
|
} break;
|
2015-11-10 07:59:53 +08:00
|
|
|
case eAddressTypeLoad:
|
2010-06-09 00:52:24 +08:00
|
|
|
m_value.SetValueType(is_instance_ptr_base
|
2015-11-10 07:59:53 +08:00
|
|
|
? Value::eValueTypeScalar
|
|
|
|
: Value::eValueTypeLoadAddress);
|
|
|
|
break;
|
|
|
|
case eAddressTypeHost:
|
|
|
|
m_value.SetValueType(Value::eValueTypeHostAddress);
|
|
|
|
break;
|
2015-08-25 07:46:31 +08:00
|
|
|
case eAddressTypeInvalid:
|
2015-11-10 07:59:53 +08:00
|
|
|
// TODO: does this make sense?
|
|
|
|
m_value.SetValueType(Value::eValueTypeScalar);
|
|
|
|
break;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
switch (value_type) {
|
2015-11-10 07:59:53 +08:00
|
|
|
case Value::eValueTypeLoadAddress:
|
2011-10-26 08:56:27 +08:00
|
|
|
case Value::eValueTypeFileAddress:
|
2015-11-10 07:59:53 +08:00
|
|
|
case Value::eValueTypeHostAddress: {
|
2010-06-09 00:52:24 +08:00
|
|
|
lldb::addr_t addr =
|
2011-10-26 08:56:27 +08:00
|
|
|
m_value.GetScalar().ULongLong(LLDB_INVALID_ADDRESS);
|
2010-11-02 09:50:16 +08:00
|
|
|
if (addr == LLDB_INVALID_ADDRESS) {
|
2011-10-26 08:56:27 +08:00
|
|
|
m_error.SetErrorString("parent address is invalid.");
|
2010-11-02 09:50:16 +08:00
|
|
|
} else if (addr == 0) {
|
|
|
|
m_error.SetErrorString("parent is NULL");
|
2011-10-26 08:56:27 +08:00
|
|
|
} else {
|
2018-05-01 00:49:04 +08:00
|
|
|
// Set this object's scalar value to the address of its value by
|
|
|
|
// adding its byte offset to the parent address
|
2011-10-26 08:56:27 +08:00
|
|
|
m_value.GetScalar() += GetByteOffset();
|
2019-08-08 06:40:05 +08:00
|
|
|
|
|
|
|
// If a bitfield doesn't fit into the child_byte_size'd
|
|
|
|
// window at child_byte_offset, move the window forward
|
|
|
|
// until it fits. The problem here is that Value has no
|
|
|
|
// notion of bitfields and thus the Value's DataExtractor
|
|
|
|
// is sized like the bitfields CompilerType; a sequence of
|
|
|
|
// bitfields, however, can be larger than their underlying
|
|
|
|
// type.
|
|
|
|
if (m_bitfield_bit_offset) {
|
|
|
|
const bool thread_and_frame_only_if_stopped = true;
|
|
|
|
ExecutionContext exe_ctx(GetExecutionContextRef().Lock(
|
|
|
|
thread_and_frame_only_if_stopped));
|
|
|
|
if (auto type_bit_size = GetCompilerType().GetBitSize(
|
|
|
|
exe_ctx.GetBestExecutionContextScope())) {
|
|
|
|
uint64_t bitfield_end =
|
|
|
|
m_bitfield_bit_size + m_bitfield_bit_offset;
|
|
|
|
if (bitfield_end > *type_bit_size) {
|
|
|
|
uint64_t overhang_bytes =
|
|
|
|
(bitfield_end - *type_bit_size + 7) / 8;
|
|
|
|
m_value.GetScalar() += overhang_bytes;
|
|
|
|
m_bitfield_bit_offset -= overhang_bytes * 8;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
} break;
|
|
|
|
|
2015-11-10 07:59:53 +08:00
|
|
|
case Value::eValueTypeScalar:
|
2011-10-26 08:56:27 +08:00
|
|
|
// try to extract the child value from the parent's scalar value
|
2016-09-07 04:57:50 +08:00
|
|
|
{
|
2011-10-26 08:56:27 +08:00
|
|
|
Scalar scalar(m_value.GetScalar());
|
2020-08-14 01:49:40 +08:00
|
|
|
scalar.ExtractBitfield(8 * m_byte_size, 8 * m_byte_offset);
|
2015-11-10 07:59:53 +08:00
|
|
|
m_value.GetScalar() = scalar;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
break;
|
2011-10-26 08:56:27 +08:00
|
|
|
default:
|
|
|
|
m_error.SetErrorString("parent has invalid value.");
|
2016-09-07 04:57:50 +08:00
|
|
|
break;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
if (m_error.Success()) {
|
2014-01-28 07:43:24 +08:00
|
|
|
const bool thread_and_frame_only_if_stopped = true;
|
|
|
|
ExecutionContext exe_ctx(
|
|
|
|
GetExecutionContextRef().Lock(thread_and_frame_only_if_stopped));
|
2015-08-25 07:46:31 +08:00
|
|
|
if (GetCompilerType().GetTypeInfo() & lldb::eTypeHasValue) {
|
2018-12-20 07:48:40 +08:00
|
|
|
Value &value = is_instance_ptr_base ? m_parent->GetValue() : m_value;
|
|
|
|
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
|
|
|
} else {
|
2014-01-24 06:55:05 +08:00
|
|
|
m_error.Clear(); // No value so nothing to read...
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
} else {
|
2010-06-09 00:52:24 +08:00
|
|
|
m_error.SetErrorStringWithFormat("parent failed to evaluate: %s",
|
|
|
|
parent->GetError().AsCString());
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
m_error.SetErrorString("ValueObjectChild has a NULL parent ValueObject.");
|
|
|
|
}
|
|
|
|
|
2011-03-31 08:19:25 +08:00
|
|
|
return m_error.Success();
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2011-03-31 08:19:25 +08:00
|
|
|
bool ValueObjectChild::IsInScope() {
|
2013-04-12 06:48:58 +08:00
|
|
|
ValueObject *root(GetRoot());
|
|
|
|
if (root)
|
|
|
|
return root->IsInScope();
|
|
|
|
return false;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|