2025-07-07 10:14:05 -07:00
|
|
|
//===-- ValueObjectSynthetic.cpp ------------------------------------===//
|
2011-07-22 00:16:08 +00:00
|
|
|
//
|
2019-01-19 08:50:56 +00: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-07-22 00:16:08 +00:00
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
2025-07-07 10:14:05 -07:00
|
|
|
#include "lldb/ValueObject/ValueObjectSynthetic.h"
|
2016-05-25 21:38:32 +00:00
|
|
|
|
2018-11-11 23:16:43 +00:00
|
|
|
#include "lldb/Core/Value.h"
|
<rdar://problem/15530080>
Rework data formatters matching algorithm
What happens now is that, for each category, the FormatNavigator generates all possible matches, and checks them one by one
Since the possible matches do not actually depend on the category (whether a match is accepted or not does, but that check can be shifted at a more convenient time),
it is actually feasible to generate every possible match upfront and then let individual categories just scan through those
This commit changes things by introducing a notion of formatters match candidate, and shifting responsibility for generating all of them given a (ValueObject,DynamicValueType) pair
from the FormatNavigator back to the FormatManager
A list of these candidates is then passed down to each category for matching
Candidates also need to remember whether they were generated by stripping pointers, references, typedefs, since this is something that individual formatters can choose to reject
This check, however, is conveniently only done once a "textual" match has been found, so that the list of candidates is truly category-independent
While the performance benefit is small (mostly, due to caching), this is much cleaner from a design perspective
llvm-svn: 195395
2013-11-22 00:02:13 +00:00
|
|
|
#include "lldb/DataFormatters/TypeSynthetic.h"
|
2018-11-11 23:16:43 +00:00
|
|
|
#include "lldb/Target/ExecutionContext.h"
|
2023-05-28 15:52:06 -07:00
|
|
|
#include "lldb/Utility/ConstString.h"
|
2022-02-03 13:26:10 +01:00
|
|
|
#include "lldb/Utility/LLDBLog.h"
|
2017-03-03 20:56:28 +00:00
|
|
|
#include "lldb/Utility/Log.h"
|
2018-11-11 23:16:43 +00:00
|
|
|
#include "lldb/Utility/Status.h"
|
2024-10-24 20:20:48 -07:00
|
|
|
#include "lldb/ValueObject/ValueObject.h"
|
2017-04-06 21:28:29 +00:00
|
|
|
|
|
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2023-01-07 13:43:00 -08:00
|
|
|
#include <optional>
|
2017-04-06 21:28:29 +00:00
|
|
|
|
|
|
|
|
namespace lldb_private {
|
|
|
|
|
class Declaration;
|
|
|
|
|
}
|
2011-07-22 00:16:08 +00:00
|
|
|
|
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
|
2012-09-14 22:41:44 +00:00
|
|
|
class DummySyntheticFrontEnd : public SyntheticChildrenFrontEnd {
|
|
|
|
|
public:
|
|
|
|
|
DummySyntheticFrontEnd(ValueObject &backend)
|
|
|
|
|
: SyntheticChildrenFrontEnd(backend) {}
|
2015-10-21 19:28:08 +00:00
|
|
|
|
2024-03-08 10:39:34 -08:00
|
|
|
llvm::Expected<uint32_t> CalculateNumChildren() override {
|
|
|
|
|
return m_backend.GetNumChildren();
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2024-03-04 17:50:47 -08:00
|
|
|
lldb::ValueObjectSP GetChildAtIndex(uint32_t idx) override {
|
2023-05-28 19:16:49 -07:00
|
|
|
return m_backend.GetChildAtIndex(idx);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2025-04-30 12:44:19 +02:00
|
|
|
llvm::Expected<size_t> GetIndexOfChildWithName(ConstString name) override {
|
2013-10-15 22:42:14 +00:00
|
|
|
return m_backend.GetIndexOfChildWithName(name);
|
2012-09-14 22:41:44 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2023-11-03 01:16:35 -04:00
|
|
|
bool MightHaveChildren() override { return m_backend.MightHaveChildren(); }
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2024-02-08 11:09:45 +00:00
|
|
|
lldb::ChildCacheState Update() override {
|
|
|
|
|
return lldb::ChildCacheState::eRefetch;
|
|
|
|
|
}
|
2012-09-14 22:41:44 +00:00
|
|
|
};
|
|
|
|
|
|
2011-07-24 00:14:56 +00:00
|
|
|
ValueObjectSynthetic::ValueObjectSynthetic(ValueObject &parent,
|
|
|
|
|
lldb::SyntheticChildrenSP filter)
|
2020-08-10 21:01:23 -07:00
|
|
|
: ValueObject(parent), m_synth_sp(std::move(filter)), m_children_byindex(),
|
2019-12-03 08:53:42 +01:00
|
|
|
m_name_toindex(), m_synthetic_children_cache(),
|
|
|
|
|
m_synthetic_children_count(UINT32_MAX),
|
|
|
|
|
m_parent_type_name(parent.GetTypeName()),
|
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-08 18:27:36 +00:00
|
|
|
m_might_have_children(eLazyBoolCalculate),
|
|
|
|
|
m_provides_value(eLazyBoolCalculate) {
|
2012-03-19 22:58:49 +00:00
|
|
|
SetName(parent.GetName());
|
2020-05-07 07:28:19 +02:00
|
|
|
// Copying the data of an incomplete type won't work as it has no byte size.
|
|
|
|
|
if (m_parent->GetCompilerType().IsCompleteType())
|
|
|
|
|
CopyValueData(m_parent);
|
2012-10-04 21:46:06 +00:00
|
|
|
CreateSynthFilter();
|
2011-07-22 00:16:08 +00:00
|
|
|
}
|
|
|
|
|
|
2015-10-26 17:00:13 +00:00
|
|
|
ValueObjectSynthetic::~ValueObjectSynthetic() = default;
|
2011-07-22 00:16:08 +00:00
|
|
|
|
2015-08-24 23:46:31 +00:00
|
|
|
CompilerType ValueObjectSynthetic::GetCompilerTypeImpl() {
|
|
|
|
|
return m_parent->GetCompilerType();
|
2011-07-22 00:16:08 +00:00
|
|
|
}
|
|
|
|
|
|
2011-07-24 00:14:56 +00:00
|
|
|
ConstString ValueObjectSynthetic::GetTypeName() {
|
2012-03-19 22:58:49 +00:00
|
|
|
return m_parent->GetTypeName();
|
2011-07-22 00:16:08 +00:00
|
|
|
}
|
|
|
|
|
|
2013-01-28 23:47:25 +00:00
|
|
|
ConstString ValueObjectSynthetic::GetQualifiedTypeName() {
|
|
|
|
|
return m_parent->GetQualifiedTypeName();
|
|
|
|
|
}
|
|
|
|
|
|
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-17 19:14:17 +00:00
|
|
|
ConstString ValueObjectSynthetic::GetDisplayTypeName() {
|
2019-02-13 06:25:41 +00:00
|
|
|
if (ConstString synth_name = m_synth_filter_up->GetSyntheticTypeName())
|
2016-05-02 00:41:24 +00:00
|
|
|
return synth_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-17 19:14:17 +00:00
|
|
|
return m_parent->GetDisplayTypeName();
|
|
|
|
|
}
|
|
|
|
|
|
2024-03-08 10:39:34 -08:00
|
|
|
llvm::Expected<uint32_t>
|
|
|
|
|
ValueObjectSynthetic::CalculateNumChildren(uint32_t max) {
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::DataFormatters);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-03-19 22:58:49 +00:00
|
|
|
UpdateValueIfNeeded();
|
2012-03-27 02:35:13 +00:00
|
|
|
if (m_synthetic_children_count < UINT32_MAX)
|
2015-10-21 19:28:08 +00:00
|
|
|
return m_synthetic_children_count <= max ? m_synthetic_children_count : max;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-10-21 19:28:08 +00:00
|
|
|
if (max < UINT32_MAX) {
|
2024-03-08 10:39:34 -08:00
|
|
|
auto num_children = m_synth_filter_up->CalculateNumChildren(max);
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"[ValueObjectSynthetic::CalculateNumChildren] for VO of name "
|
2024-03-08 10:39:34 -08:00
|
|
|
"%s and type %s, the filter returned %u child values",
|
|
|
|
|
GetName().AsCString(), GetTypeName().AsCString(),
|
|
|
|
|
num_children ? *num_children : 0);
|
2016-05-25 21:38:32 +00:00
|
|
|
return num_children;
|
2015-10-21 19:28:08 +00:00
|
|
|
} else {
|
2024-03-08 10:39:34 -08:00
|
|
|
auto num_children_or_err = m_synth_filter_up->CalculateNumChildren(max);
|
|
|
|
|
if (!num_children_or_err) {
|
|
|
|
|
m_synthetic_children_count = 0;
|
|
|
|
|
return num_children_or_err;
|
|
|
|
|
}
|
|
|
|
|
auto num_children = (m_synthetic_children_count = *num_children_or_err);
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"[ValueObjectSynthetic::CalculateNumChildren] for VO of name "
|
2024-03-08 10:39:34 -08:00
|
|
|
"%s and type %s, the filter returned %u child values",
|
2019-07-24 17:56:10 +00:00
|
|
|
GetName().AsCString(), GetTypeName().AsCString(), num_children);
|
2016-05-25 21:38:32 +00:00
|
|
|
return num_children;
|
|
|
|
|
}
|
2011-07-22 00:16:08 +00:00
|
|
|
}
|
|
|
|
|
|
2013-01-28 23:47:25 +00:00
|
|
|
lldb::ValueObjectSP
|
|
|
|
|
ValueObjectSynthetic::GetDynamicValue(lldb::DynamicValueType valueType) {
|
|
|
|
|
if (!m_parent)
|
|
|
|
|
return lldb::ValueObjectSP();
|
2013-02-19 22:03:00 +00:00
|
|
|
if (IsDynamic() && GetDynamicValueType() == valueType)
|
|
|
|
|
return GetSP();
|
|
|
|
|
return m_parent->GetDynamicValue(valueType);
|
2013-01-28 23:47:25 +00:00
|
|
|
}
|
|
|
|
|
|
2012-10-23 01:50:10 +00:00
|
|
|
bool ValueObjectSynthetic::MightHaveChildren() {
|
2012-10-23 19:54:09 +00:00
|
|
|
if (m_might_have_children == eLazyBoolCalculate)
|
|
|
|
|
m_might_have_children =
|
2019-02-13 06:25:41 +00:00
|
|
|
(m_synth_filter_up->MightHaveChildren() ? eLazyBoolYes : eLazyBoolNo);
|
2018-12-15 00:15:33 +00:00
|
|
|
return (m_might_have_children != eLazyBoolNo);
|
2012-10-23 01:50:10 +00:00
|
|
|
}
|
|
|
|
|
|
2025-03-05 10:21:19 -08:00
|
|
|
llvm::Expected<uint64_t> ValueObjectSynthetic::GetByteSize() {
|
2020-07-25 08:27:21 -07:00
|
|
|
return m_parent->GetByteSize();
|
|
|
|
|
}
|
2011-07-22 00:16:08 +00:00
|
|
|
|
2011-07-24 00:14:56 +00:00
|
|
|
lldb::ValueType ValueObjectSynthetic::GetValueType() const {
|
2011-07-22 00:16:08 +00:00
|
|
|
return m_parent->GetValueType();
|
|
|
|
|
}
|
|
|
|
|
|
2012-10-04 21:46:06 +00:00
|
|
|
void ValueObjectSynthetic::CreateSynthFilter() {
|
2018-07-13 19:28:32 +00:00
|
|
|
ValueObject *valobj_for_frontend = m_parent;
|
2024-10-24 20:20:48 -07:00
|
|
|
if (m_synth_sp->WantsDereference()) {
|
2018-07-13 19:28:32 +00:00
|
|
|
CompilerType type = m_parent->GetCompilerType();
|
2024-10-24 20:20:48 -07:00
|
|
|
if (type.IsValid() && type.IsPointerOrReferenceType()) {
|
2018-07-13 19:28:32 +00:00
|
|
|
Status error;
|
|
|
|
|
lldb::ValueObjectSP deref_sp = m_parent->Dereference(error);
|
|
|
|
|
if (error.Success())
|
|
|
|
|
valobj_for_frontend = deref_sp.get();
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-02-13 06:25:41 +00:00
|
|
|
m_synth_filter_up = (m_synth_sp->GetFrontEnd(*valobj_for_frontend));
|
|
|
|
|
if (!m_synth_filter_up)
|
2019-08-14 22:19:23 +00:00
|
|
|
m_synth_filter_up = std::make_unique<DummySyntheticFrontEnd>(*m_parent);
|
2012-10-04 21:46:06 +00:00
|
|
|
}
|
|
|
|
|
|
2011-07-24 00:14:56 +00:00
|
|
|
bool ValueObjectSynthetic::UpdateValue() {
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::DataFormatters);
|
2011-07-22 00:16:08 +00:00
|
|
|
|
2016-05-25 21:38:32 +00:00
|
|
|
SetValueIsValid(false);
|
|
|
|
|
m_error.Clear();
|
|
|
|
|
|
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-08 18:27:36 +00:00
|
|
|
if (!m_parent->UpdateValueIfNeeded(false)) {
|
|
|
|
|
// our parent could not update.. as we are meaningless without a parent,
|
|
|
|
|
// just stop
|
|
|
|
|
if (m_parent->GetError().Fail())
|
2024-09-05 12:44:13 -07:00
|
|
|
m_error = m_parent->GetError().Clone();
|
2011-07-22 00:16:08 +00:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2023-07-30 14:28:28 -07:00
|
|
|
// Regenerate the synthetic filter if our typename changes. When the (dynamic)
|
|
|
|
|
// type of an object changes, so does their synthetic filter of choice.
|
2016-05-25 21:38:32 +00:00
|
|
|
ConstString new_parent_type_name = m_parent->GetTypeName();
|
|
|
|
|
if (new_parent_type_name != m_parent_type_name) {
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"[ValueObjectSynthetic::UpdateValue] name=%s, type changed "
|
|
|
|
|
"from %s to %s, recomputing synthetic filter",
|
|
|
|
|
GetName().AsCString(), m_parent_type_name.AsCString(),
|
|
|
|
|
new_parent_type_name.AsCString());
|
Because of our lifetime rules w.r.t. ValueObjects and ClusterManagers, synthetic children caching is a tricky area:
- if a synthetic child comes from the same hierarchy as its parent object, then it can't be cached by SharedPointer inside the synthetic provider, or it will cause a reference loop;
- but, if a synthetic child is made from whole cloth (e.g. from an expression, a memory region, ...), then it better be cached by SharedPointer, or it will be cleared out and cause an assert() to fail if used at a later point
For most cases of self-rooted synthetic children, we have a flag we set "IsSyntheticChildrenGenerated", but we were not using it to track caching. So, what ended up happening is each provider would set up its own cache, and if it got it wrong, a hard to diagnose crash would ensue
This patch fixes that by centralizing caching in ValueObjectSynthetic - if a provider returns a self-rooted child (as per the flag), then it gets cached centrally by the ValueObject itself
This cache is used only for lifetime management and not later retrieval of child values - a different cache handles that (because we might have a mix of self-rooted and properly nested child values for the same parent, we can't trivially use this lifetime cache for retrieval)
Fixes rdar://26480007
llvm-svn: 274683
2016-07-06 21:24:28 +00:00
|
|
|
m_parent_type_name = new_parent_type_name;
|
2016-07-28 18:19:33 +00:00
|
|
|
CreateSynthFilter();
|
2011-07-24 00:14:56 +00:00
|
|
|
}
|
2016-05-25 21:38:32 +00:00
|
|
|
|
2015-01-09 19:47:45 +00:00
|
|
|
// let our backend do its update
|
2024-02-08 11:09:45 +00:00
|
|
|
if (m_synth_filter_up->Update() == lldb::ChildCacheState::eRefetch) {
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"[ValueObjectSynthetic::UpdateValue] name=%s, synthetic "
|
|
|
|
|
"filter said caches are stale - clearing",
|
|
|
|
|
GetName().AsCString());
|
2012-03-19 22:58:49 +00:00
|
|
|
// filter said that cached values are stale
|
2019-12-03 08:53:42 +01:00
|
|
|
{
|
|
|
|
|
std::lock_guard<std::mutex> guard(m_child_mutex);
|
|
|
|
|
m_children_byindex.clear();
|
|
|
|
|
m_name_toindex.clear();
|
|
|
|
|
}
|
2015-01-09 19:47:45 +00:00
|
|
|
// usually, an object's value can change but this does not alter its
|
2018-04-30 16:49:04 +00:00
|
|
|
// children count for a synthetic VO that might indeed happen, so we need
|
|
|
|
|
// to tell the upper echelons that they need to come back to us asking for
|
|
|
|
|
// children
|
2021-02-23 09:38:34 +01:00
|
|
|
m_flags.m_children_count_valid = false;
|
2019-12-03 08:53:42 +01:00
|
|
|
{
|
|
|
|
|
std::lock_guard<std::mutex> guard(m_child_mutex);
|
|
|
|
|
m_synthetic_children_cache.clear();
|
|
|
|
|
}
|
2012-03-27 02:35:13 +00:00
|
|
|
m_synthetic_children_count = UINT32_MAX;
|
2012-10-23 19:54:09 +00:00
|
|
|
m_might_have_children = eLazyBoolCalculate;
|
2011-07-22 00:16:08 +00:00
|
|
|
} else {
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"[ValueObjectSynthetic::UpdateValue] name=%s, synthetic "
|
|
|
|
|
"filter said caches are still valid",
|
|
|
|
|
GetName().AsCString());
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2011-07-22 00:16:08 +00:00
|
|
|
|
2011-07-24 00:14:56 +00:00
|
|
|
m_provides_value = eLazyBoolCalculate;
|
2012-03-19 22:58:49 +00:00
|
|
|
|
2019-02-13 06:25:41 +00:00
|
|
|
lldb::ValueObjectSP synth_val(m_synth_filter_up->GetSyntheticValue());
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-07-24 00:14:56 +00:00
|
|
|
if (synth_val && synth_val->CanProvideValue()) {
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"[ValueObjectSynthetic::UpdateValue] name=%s, synthetic "
|
|
|
|
|
"filter said it can provide a value",
|
|
|
|
|
GetName().AsCString());
|
2016-09-06 20:57:50 +00: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-08 18:27:36 +00:00
|
|
|
m_provides_value = eLazyBoolYes;
|
|
|
|
|
CopyValueData(synth_val.get());
|
2016-09-06 20:57:50 +00:00
|
|
|
} else {
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"[ValueObjectSynthetic::UpdateValue] name=%s, synthetic "
|
|
|
|
|
"filter said it will not provide a value",
|
|
|
|
|
GetName().AsCString());
|
2016-09-06 20:57:50 +00: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-08 18:27:36 +00:00
|
|
|
m_provides_value = eLazyBoolNo;
|
2020-05-07 07:28:19 +02:00
|
|
|
// Copying the data of an incomplete type won't work as it has no byte size.
|
|
|
|
|
if (m_parent->GetCompilerType().IsCompleteType())
|
|
|
|
|
CopyValueData(m_parent);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2011-07-24 00:14:56 +00:00
|
|
|
SetValueIsValid(true);
|
|
|
|
|
return true;
|
2011-07-22 00:16:08 +00:00
|
|
|
}
|
|
|
|
|
|
2024-03-04 17:50:47 -08:00
|
|
|
lldb::ValueObjectSP ValueObjectSynthetic::GetChildAtIndex(uint32_t idx,
|
2011-07-24 00:14:56 +00:00
|
|
|
bool can_create) {
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::DataFormatters);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"[ValueObjectSynthetic::GetChildAtIndex] name=%s, retrieving "
|
2024-03-04 17:50:47 -08:00
|
|
|
"child at index %u",
|
2019-07-24 17:56:10 +00:00
|
|
|
GetName().AsCString(), idx);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-03-19 22:58:49 +00:00
|
|
|
UpdateValueIfNeeded();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-01-09 19:47:45 +00:00
|
|
|
ValueObject *valobj;
|
2019-12-03 08:53:42 +01:00
|
|
|
bool child_is_cached;
|
|
|
|
|
{
|
|
|
|
|
std::lock_guard<std::mutex> guard(m_child_mutex);
|
|
|
|
|
auto cached_child_it = m_children_byindex.find(idx);
|
|
|
|
|
child_is_cached = cached_child_it != m_children_byindex.end();
|
|
|
|
|
if (child_is_cached)
|
|
|
|
|
valobj = cached_child_it->second;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!child_is_cached) {
|
2019-02-13 06:25:41 +00:00
|
|
|
if (can_create && m_synth_filter_up != nullptr) {
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"[ValueObjectSynthetic::GetChildAtIndex] name=%s, child at "
|
2024-03-04 17:50:47 -08:00
|
|
|
"index %u not cached and will be created",
|
2019-07-24 17:56:10 +00:00
|
|
|
GetName().AsCString(), idx);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-02-13 06:25:41 +00:00
|
|
|
lldb::ValueObjectSP synth_guy = m_synth_filter_up->GetChildAtIndex(idx);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(
|
|
|
|
|
log,
|
|
|
|
|
"[ValueObjectSynthetic::GetChildAtIndex] name=%s, child at index "
|
2024-03-04 17:50:47 -08:00
|
|
|
"%u created as %p (is "
|
2019-07-24 17:56:10 +00:00
|
|
|
"synthetic: %s)",
|
|
|
|
|
GetName().AsCString(), idx, static_cast<void *>(synth_guy.get()),
|
|
|
|
|
synth_guy.get()
|
|
|
|
|
? (synth_guy->IsSyntheticChildrenGenerated() ? "yes" : "no")
|
|
|
|
|
: "no");
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-03-20 18:02:56 +00:00
|
|
|
if (!synth_guy)
|
|
|
|
|
return synth_guy;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-12-03 08:53:42 +01:00
|
|
|
{
|
|
|
|
|
std::lock_guard<std::mutex> guard(m_child_mutex);
|
|
|
|
|
if (synth_guy->IsSyntheticChildrenGenerated())
|
|
|
|
|
m_synthetic_children_cache.push_back(synth_guy);
|
|
|
|
|
m_children_byindex[idx] = synth_guy.get();
|
|
|
|
|
}
|
2015-10-07 02:36:35 +00:00
|
|
|
synth_guy->SetPreferredDisplayLanguageIfNeeded(
|
|
|
|
|
GetPreferredDisplayLanguage());
|
2012-03-20 18:02:56 +00:00
|
|
|
return synth_guy;
|
2016-09-06 20:57:50 +00:00
|
|
|
} else {
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"[ValueObjectSynthetic::GetChildAtIndex] name=%s, child at "
|
2024-03-04 17:50:47 -08:00
|
|
|
"index %u not cached and cannot "
|
2019-07-24 17:56:10 +00:00
|
|
|
"be created (can_create = %s, synth_filter = %p)",
|
|
|
|
|
GetName().AsCString(), idx, can_create ? "yes" : "no",
|
|
|
|
|
static_cast<void *>(m_synth_filter_up.get()));
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-07-24 00:14:56 +00:00
|
|
|
return lldb::ValueObjectSP();
|
2011-07-22 00:16:08 +00:00
|
|
|
}
|
2015-10-26 17:00:13 +00:00
|
|
|
} else {
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"[ValueObjectSynthetic::GetChildAtIndex] name=%s, child at "
|
2024-03-04 17:50:47 -08:00
|
|
|
"index %u cached as %p",
|
2019-07-24 17:56:10 +00:00
|
|
|
GetName().AsCString(), idx, static_cast<void *>(valobj));
|
2011-07-22 00:16:08 +00:00
|
|
|
|
|
|
|
|
return valobj->GetSP();
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2011-07-22 00:16:08 +00:00
|
|
|
}
|
|
|
|
|
|
2012-05-08 18:47:08 +00:00
|
|
|
lldb::ValueObjectSP
|
2023-05-26 21:19:10 -07:00
|
|
|
ValueObjectSynthetic::GetChildMemberWithName(llvm::StringRef name,
|
2012-05-08 18:47:08 +00:00
|
|
|
bool can_create) {
|
|
|
|
|
UpdateValueIfNeeded();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2025-04-30 12:44:19 +02:00
|
|
|
auto index_or_err = GetIndexOfChildWithName(name);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2025-04-30 12:44:19 +02:00
|
|
|
if (!index_or_err) {
|
|
|
|
|
llvm::consumeError(index_or_err.takeError());
|
2012-05-08 18:47:08 +00:00
|
|
|
return lldb::ValueObjectSP();
|
2025-04-30 12:44:19 +02:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2025-04-30 12:44:19 +02:00
|
|
|
return GetChildAtIndex(*index_or_err, can_create);
|
2012-05-08 18:47:08 +00:00
|
|
|
}
|
2012-10-22 18:18:36 +00:00
|
|
|
|
2025-04-30 12:44:19 +02:00
|
|
|
llvm::Expected<size_t>
|
|
|
|
|
ValueObjectSynthetic::GetIndexOfChildWithName(llvm::StringRef name_ref) {
|
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-08 18:27:36 +00:00
|
|
|
UpdateValueIfNeeded();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2023-05-28 15:52:06 -07:00
|
|
|
ConstString name(name_ref);
|
|
|
|
|
|
2025-04-30 12:44:19 +02:00
|
|
|
std::optional<uint32_t> found_index = std::nullopt;
|
2019-12-03 08:53:42 +01:00
|
|
|
{
|
|
|
|
|
std::lock_guard<std::mutex> guard(m_child_mutex);
|
|
|
|
|
auto name_to_index = m_name_toindex.find(name.GetCString());
|
2025-04-30 12:44:19 +02:00
|
|
|
if (name_to_index != m_name_toindex.end())
|
2019-12-03 08:53:42 +01:00
|
|
|
found_index = name_to_index->second;
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2025-04-30 12:44:19 +02:00
|
|
|
if (!found_index && m_synth_filter_up != nullptr) {
|
|
|
|
|
auto index_or_err = m_synth_filter_up->GetIndexOfChildWithName(name);
|
|
|
|
|
if (!index_or_err)
|
|
|
|
|
return index_or_err.takeError();
|
2019-12-03 08:53:42 +01:00
|
|
|
std::lock_guard<std::mutex> guard(m_child_mutex);
|
2025-04-30 12:44:19 +02:00
|
|
|
m_name_toindex[name.GetCString()] = *index_or_err;
|
|
|
|
|
return *index_or_err;
|
|
|
|
|
} else if (!found_index && m_synth_filter_up == nullptr) {
|
|
|
|
|
return llvm::createStringError("Type has no child named '%s'",
|
|
|
|
|
name.AsCString());
|
|
|
|
|
} else if (found_index)
|
|
|
|
|
return *found_index;
|
|
|
|
|
|
|
|
|
|
return llvm::createStringError("Type has no child named '%s'",
|
|
|
|
|
name.AsCString());
|
2012-10-22 18:18:36 +00: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-08 18:27:36 +00:00
|
|
|
|
|
|
|
|
bool ValueObjectSynthetic::IsInScope() { return m_parent->IsInScope(); }
|
2016-09-06 20:57:50 +00: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-08 18:27:36 +00:00
|
|
|
lldb::ValueObjectSP ValueObjectSynthetic::GetNonSyntheticValue() {
|
|
|
|
|
return m_parent->GetSP();
|
|
|
|
|
}
|
2015-01-26 19:33:52 +00:00
|
|
|
|
|
|
|
|
void ValueObjectSynthetic::CopyValueData(ValueObject *source) {
|
2025-03-16 08:41:55 -07:00
|
|
|
if (!source->UpdateValueIfNeeded())
|
|
|
|
|
return;
|
|
|
|
|
m_value = source->GetValue();
|
2015-01-26 19:33:52 +00:00
|
|
|
ExecutionContext exe_ctx(GetExecutionContextRef());
|
2019-08-08 19:22:32 +00:00
|
|
|
m_error = m_value.GetValueAsData(&exe_ctx, m_data, GetModule().get());
|
2015-01-26 19:33:52 +00:00
|
|
|
}
|
2015-05-07 20:33:31 +00:00
|
|
|
|
|
|
|
|
bool ValueObjectSynthetic::CanProvideValue() {
|
|
|
|
|
if (!UpdateValueIfNeeded())
|
|
|
|
|
return false;
|
|
|
|
|
if (m_provides_value == eLazyBoolYes)
|
|
|
|
|
return true;
|
|
|
|
|
return m_parent->CanProvideValue();
|
|
|
|
|
}
|
2015-08-18 17:56:06 +00:00
|
|
|
|
2015-10-07 02:36:35 +00:00
|
|
|
bool ValueObjectSynthetic::SetValueFromCString(const char *value_str,
|
2017-05-12 04:51:55 +00:00
|
|
|
Status &error) {
|
2015-10-07 02:36:35 +00:00
|
|
|
return m_parent->SetValueFromCString(value_str, error);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ValueObjectSynthetic::SetFormat(lldb::Format format) {
|
|
|
|
|
if (m_parent) {
|
|
|
|
|
m_parent->ClearUserVisibleData(eClearUserVisibleDataItemsAll);
|
|
|
|
|
m_parent->SetFormat(format);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2015-05-07 20:33:31 +00:00
|
|
|
this->ValueObject::SetFormat(format);
|
2015-10-07 02:36:35 +00:00
|
|
|
this->ClearUserVisibleData(eClearUserVisibleDataItemsAll);
|
|
|
|
|
}
|
|
|
|
|
|
2016-07-08 18:39:36 +00:00
|
|
|
void ValueObjectSynthetic::SetPreferredDisplayLanguage(
|
|
|
|
|
lldb::LanguageType lang) {
|
|
|
|
|
this->ValueObject::SetPreferredDisplayLanguage(lang);
|
|
|
|
|
if (m_parent)
|
|
|
|
|
m_parent->SetPreferredDisplayLanguage(lang);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
lldb::LanguageType ValueObjectSynthetic::GetPreferredDisplayLanguage() {
|
|
|
|
|
if (m_preferred_display_language == lldb::eLanguageTypeUnknown) {
|
|
|
|
|
if (m_parent)
|
|
|
|
|
return m_parent->GetPreferredDisplayLanguage();
|
|
|
|
|
return lldb::eLanguageTypeUnknown;
|
|
|
|
|
} else
|
|
|
|
|
return m_preferred_display_language;
|
|
|
|
|
}
|
|
|
|
|
|
2015-08-18 17:56:06 +00:00
|
|
|
bool ValueObjectSynthetic::IsSyntheticChildrenGenerated() {
|
|
|
|
|
if (m_parent)
|
|
|
|
|
return m_parent->IsSyntheticChildrenGenerated();
|
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-08 18:27:36 +00:00
|
|
|
return false;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2015-08-18 17:56:06 +00:00
|
|
|
|
|
|
|
|
void ValueObjectSynthetic::SetSyntheticChildrenGenerated(bool b) {
|
|
|
|
|
if (m_parent)
|
Because of our lifetime rules w.r.t. ValueObjects and ClusterManagers, synthetic children caching is a tricky area:
- if a synthetic child comes from the same hierarchy as its parent object, then it can't be cached by SharedPointer inside the synthetic provider, or it will cause a reference loop;
- but, if a synthetic child is made from whole cloth (e.g. from an expression, a memory region, ...), then it better be cached by SharedPointer, or it will be cleared out and cause an assert() to fail if used at a later point
For most cases of self-rooted synthetic children, we have a flag we set "IsSyntheticChildrenGenerated", but we were not using it to track caching. So, what ended up happening is each provider would set up its own cache, and if it got it wrong, a hard to diagnose crash would ensue
This patch fixes that by centralizing caching in ValueObjectSynthetic - if a provider returns a self-rooted child (as per the flag), then it gets cached centrally by the ValueObject itself
This cache is used only for lifetime management and not later retrieval of child values - a different cache handles that (because we might have a mix of self-rooted and properly nested child values for the same parent, we can't trivially use this lifetime cache for retrieval)
Fixes rdar://26480007
llvm-svn: 274683
2016-07-06 21:24:28 +00:00
|
|
|
m_parent->SetSyntheticChildrenGenerated(b);
|
2015-08-18 17:56:06 +00:00
|
|
|
this->ValueObject::SetSyntheticChildrenGenerated(b);
|
|
|
|
|
}
|
2015-11-09 19:27:34 +00:00
|
|
|
|
|
|
|
|
bool ValueObjectSynthetic::GetDeclaration(Declaration &decl) {
|
|
|
|
|
if (m_parent)
|
|
|
|
|
return m_parent->GetDeclaration(decl);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-11-09 19:27:34 +00:00
|
|
|
return ValueObject::GetDeclaration(decl);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
uint64_t ValueObjectSynthetic::GetLanguageFlags() {
|
|
|
|
|
if (m_parent)
|
2012-03-19 22:58:49 +00:00
|
|
|
return m_parent->GetLanguageFlags();
|
2015-10-07 02:36:35 +00:00
|
|
|
return this->ValueObject::GetLanguageFlags();
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2015-11-09 19:27:34 +00:00
|
|
|
void ValueObjectSynthetic::SetLanguageFlags(uint64_t flags) {
|
|
|
|
|
if (m_parent)
|
|
|
|
|
m_parent->SetLanguageFlags(flags);
|
|
|
|
|
else
|
|
|
|
|
this->ValueObject::SetLanguageFlags(flags);
|
|
|
|
|
}
|