2011-04-16 08:01:13 +08:00
|
|
|
//===-- ValueObjectDynamicValue.cpp ---------------------------------*- C++ -*-===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
|
|
|
|
#include "lldb/Core/ValueObjectDynamicValue.h"
|
|
|
|
|
|
|
|
// C Includes
|
|
|
|
// C++ Includes
|
|
|
|
// Other libraries and framework includes
|
|
|
|
// Project includes
|
2012-10-18 06:23:56 +08:00
|
|
|
#include "lldb/Core/Log.h"
|
2011-04-16 08:01:13 +08:00
|
|
|
#include "lldb/Core/Module.h"
|
|
|
|
#include "lldb/Core/ValueObjectList.h"
|
|
|
|
#include "lldb/Core/Value.h"
|
|
|
|
#include "lldb/Core/ValueObject.h"
|
|
|
|
|
2012-10-27 10:05:48 +08:00
|
|
|
#include "lldb/Symbol/ClangASTType.h"
|
2011-04-16 08:01:13 +08:00
|
|
|
#include "lldb/Symbol/ObjectFile.h"
|
|
|
|
#include "lldb/Symbol/SymbolContext.h"
|
|
|
|
#include "lldb/Symbol/Type.h"
|
|
|
|
#include "lldb/Symbol/Variable.h"
|
|
|
|
|
|
|
|
#include "lldb/Target/ExecutionContext.h"
|
|
|
|
#include "lldb/Target/LanguageRuntime.h"
|
|
|
|
#include "lldb/Target/Process.h"
|
|
|
|
#include "lldb/Target/RegisterContext.h"
|
|
|
|
#include "lldb/Target/Target.h"
|
|
|
|
#include "lldb/Target/Thread.h"
|
|
|
|
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
2011-05-04 11:43:18 +08:00
|
|
|
ValueObjectDynamicValue::ValueObjectDynamicValue (ValueObject &parent, lldb::DynamicValueType use_dynamic) :
|
2011-04-16 08:01:13 +08:00
|
|
|
ValueObject(parent),
|
|
|
|
m_address (),
|
2013-01-23 09:17:27 +08:00
|
|
|
m_dynamic_type_info(),
|
2011-05-04 11:43:18 +08:00
|
|
|
m_use_dynamic (use_dynamic)
|
2011-04-16 08:01:13 +08:00
|
|
|
{
|
2011-07-30 03:53:35 +08:00
|
|
|
SetName (parent.GetName());
|
2011-04-16 08:01:13 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
ValueObjectDynamicValue::~ValueObjectDynamicValue()
|
|
|
|
{
|
|
|
|
m_owning_valobj_sp.reset();
|
|
|
|
}
|
|
|
|
|
2013-07-12 06:46:58 +08:00
|
|
|
ClangASTType
|
2012-02-23 07:57:45 +08:00
|
|
|
ValueObjectDynamicValue::GetClangTypeImpl ()
|
2011-04-16 08:01:13 +08:00
|
|
|
{
|
2013-10-29 08:28:35 +08:00
|
|
|
const bool success = UpdateValueIfNeeded(false);
|
|
|
|
if (success)
|
|
|
|
{
|
|
|
|
if (m_dynamic_type_info.HasType())
|
|
|
|
return m_value.GetClangType();
|
|
|
|
else
|
|
|
|
return m_parent->GetClangType();
|
|
|
|
}
|
|
|
|
return m_parent->GetClangType();
|
2011-04-16 08:01:13 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
ConstString
|
|
|
|
ValueObjectDynamicValue::GetTypeName()
|
|
|
|
{
|
2011-08-03 01:27:39 +08:00
|
|
|
const bool success = UpdateValueIfNeeded(false);
|
2013-01-23 09:17:27 +08:00
|
|
|
if (success)
|
|
|
|
{
|
|
|
|
if (m_dynamic_type_info.HasName())
|
|
|
|
return m_dynamic_type_info.GetName();
|
|
|
|
}
|
|
|
|
return m_parent->GetTypeName();
|
|
|
|
}
|
|
|
|
|
2013-10-29 08:28:35 +08:00
|
|
|
TypeImpl
|
|
|
|
ValueObjectDynamicValue::GetTypeImpl ()
|
|
|
|
{
|
|
|
|
const bool success = UpdateValueIfNeeded(false);
|
2013-10-30 01:42:02 +08:00
|
|
|
if (success && m_type_impl.IsValid())
|
2013-10-29 08:28:35 +08:00
|
|
|
{
|
|
|
|
return m_type_impl;
|
|
|
|
}
|
|
|
|
return m_parent->GetTypeImpl();
|
|
|
|
}
|
|
|
|
|
2013-01-23 09:17:27 +08:00
|
|
|
ConstString
|
|
|
|
ValueObjectDynamicValue::GetQualifiedTypeName()
|
|
|
|
{
|
|
|
|
const bool success = UpdateValueIfNeeded(false);
|
|
|
|
if (success)
|
|
|
|
{
|
|
|
|
if (m_dynamic_type_info.HasName())
|
|
|
|
return m_dynamic_type_info.GetName();
|
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 m_parent->GetQualifiedTypeName();
|
|
|
|
}
|
|
|
|
|
|
|
|
ConstString
|
|
|
|
ValueObjectDynamicValue::GetDisplayTypeName()
|
|
|
|
{
|
|
|
|
const bool success = UpdateValueIfNeeded(false);
|
|
|
|
if (success)
|
|
|
|
{
|
2013-11-01 06:42:00 +08:00
|
|
|
if (m_dynamic_type_info.HasType())
|
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 GetClangType().GetDisplayTypeName();
|
|
|
|
if (m_dynamic_type_info.HasName())
|
|
|
|
return m_dynamic_type_info.GetName();
|
2013-01-23 09:17:27 +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
|
|
|
return m_parent->GetDisplayTypeName();
|
2011-04-16 08:01:13 +08:00
|
|
|
}
|
|
|
|
|
2013-01-26 02:06:21 +08:00
|
|
|
size_t
|
2011-04-16 08:01:13 +08:00
|
|
|
ValueObjectDynamicValue::CalculateNumChildren()
|
|
|
|
{
|
2011-08-03 01:27:39 +08:00
|
|
|
const bool success = UpdateValueIfNeeded(false);
|
2013-10-29 08:28:35 +08:00
|
|
|
if (success && m_dynamic_type_info.HasType())
|
2013-07-12 06:46:58 +08:00
|
|
|
return GetClangType().GetNumChildren (true);
|
2011-04-16 08:01:13 +08:00
|
|
|
else
|
|
|
|
return m_parent->GetNumChildren();
|
|
|
|
}
|
|
|
|
|
2013-03-15 02:31:44 +08:00
|
|
|
uint64_t
|
2011-04-16 08:01:13 +08:00
|
|
|
ValueObjectDynamicValue::GetByteSize()
|
|
|
|
{
|
2011-08-03 01:27:39 +08:00
|
|
|
const bool success = UpdateValueIfNeeded(false);
|
2013-10-29 08:28:35 +08:00
|
|
|
if (success && m_dynamic_type_info.HasType())
|
2015-01-28 09:09:45 +08:00
|
|
|
return m_value.GetValueByteSize(nullptr);
|
2011-04-16 08:01:13 +08:00
|
|
|
else
|
|
|
|
return m_parent->GetByteSize();
|
|
|
|
}
|
|
|
|
|
|
|
|
lldb::ValueType
|
|
|
|
ValueObjectDynamicValue::GetValueType() const
|
|
|
|
{
|
|
|
|
return m_parent->GetValueType();
|
|
|
|
}
|
|
|
|
|
2013-10-29 08:28:35 +08:00
|
|
|
|
|
|
|
static TypeAndOrName
|
|
|
|
FixupTypeAndOrName (const TypeAndOrName& type_andor_name,
|
|
|
|
ValueObject& parent)
|
|
|
|
{
|
|
|
|
TypeAndOrName ret(type_andor_name);
|
|
|
|
if (type_andor_name.HasType())
|
|
|
|
{
|
|
|
|
// The type will always be the type of the dynamic object. If our parent's type was a pointer,
|
|
|
|
// then our type should be a pointer to the type of the dynamic object. If a reference, then the original type
|
|
|
|
// should be okay...
|
|
|
|
ClangASTType orig_type = type_andor_name.GetClangASTType();
|
|
|
|
ClangASTType corrected_type = orig_type;
|
|
|
|
if (parent.IsPointerType())
|
|
|
|
corrected_type = orig_type.GetPointerType ();
|
|
|
|
else if (parent.IsPointerOrReferenceType())
|
|
|
|
corrected_type = orig_type.GetLValueReferenceType ();
|
|
|
|
ret.SetClangASTType(corrected_type);
|
|
|
|
}
|
|
|
|
else /*if (m_dynamic_type_info.HasName())*/
|
|
|
|
{
|
|
|
|
// If we are here we need to adjust our dynamic type name to include the correct & or * symbol
|
|
|
|
std::string corrected_name (type_andor_name.GetName().GetCString());
|
|
|
|
if (parent.IsPointerType())
|
|
|
|
corrected_name.append(" *");
|
|
|
|
else if (parent.IsPointerOrReferenceType())
|
|
|
|
corrected_name.append(" &");
|
2013-11-01 06:42:00 +08:00
|
|
|
// the parent type should be a correctly pointer'ed or referenc'ed type
|
|
|
|
ret.SetClangASTType(parent.GetClangType());
|
2013-10-29 08:28:35 +08:00
|
|
|
ret.SetName(corrected_name.c_str());
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2011-04-16 08:01:13 +08:00
|
|
|
bool
|
|
|
|
ValueObjectDynamicValue::UpdateValue ()
|
|
|
|
{
|
|
|
|
SetValueIsValid (false);
|
|
|
|
m_error.Clear();
|
|
|
|
|
2011-08-03 01:27:39 +08:00
|
|
|
if (!m_parent->UpdateValueIfNeeded(false))
|
2011-04-16 08:01:13 +08:00
|
|
|
{
|
2011-05-30 08:49:24 +08:00
|
|
|
// The dynamic value failed to get an error, pass the error along
|
|
|
|
if (m_error.Success() && m_parent->GetError().Fail())
|
|
|
|
m_error = m_parent->GetError();
|
2011-04-16 08:01:13 +08:00
|
|
|
return false;
|
|
|
|
}
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2011-05-04 11:43:18 +08:00
|
|
|
// Setting our type_sp to NULL will route everything back through our
|
|
|
|
// parent which is equivalent to not using dynamic values.
|
|
|
|
if (m_use_dynamic == lldb::eNoDynamicValues)
|
|
|
|
{
|
2013-01-23 09:17:27 +08:00
|
|
|
m_dynamic_type_info.Clear();
|
2011-05-04 11:43:18 +08:00
|
|
|
return true;
|
|
|
|
}
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2012-02-17 15:49:44 +08:00
|
|
|
ExecutionContext exe_ctx (GetExecutionContextRef());
|
2011-09-22 12:58:26 +08:00
|
|
|
Target *target = exe_ctx.GetTargetPtr();
|
|
|
|
if (target)
|
2011-04-16 08:01:13 +08:00
|
|
|
{
|
2011-09-22 12:58:26 +08:00
|
|
|
m_data.SetByteOrder(target->GetArchitecture().GetByteOrder());
|
|
|
|
m_data.SetAddressByteSize(target->GetArchitecture().GetAddressByteSize());
|
2011-04-16 08:01:13 +08:00
|
|
|
}
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2011-04-16 08:01:13 +08:00
|
|
|
// First make sure our Type and/or Address haven't changed:
|
2012-02-17 15:49:44 +08:00
|
|
|
Process *process = exe_ctx.GetProcessPtr();
|
2011-04-16 08:01:13 +08:00
|
|
|
if (!process)
|
|
|
|
return false;
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2011-05-03 02:13:59 +08:00
|
|
|
TypeAndOrName class_type_or_name;
|
2011-04-16 08:01:13 +08:00
|
|
|
Address dynamic_address;
|
|
|
|
bool found_dynamic_type = false;
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2011-04-16 08:01:13 +08:00
|
|
|
lldb::LanguageType known_type = m_parent->GetObjectRuntimeLanguage();
|
|
|
|
if (known_type != lldb::eLanguageTypeUnknown && known_type != lldb::eLanguageTypeC)
|
|
|
|
{
|
|
|
|
LanguageRuntime *runtime = process->GetLanguageRuntime (known_type);
|
|
|
|
if (runtime)
|
2011-05-04 11:43:18 +08:00
|
|
|
found_dynamic_type = runtime->GetDynamicTypeAndAddress (*m_parent, m_use_dynamic, class_type_or_name, dynamic_address);
|
2011-04-16 08:01:13 +08:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
LanguageRuntime *cpp_runtime = process->GetLanguageRuntime (lldb::eLanguageTypeC_plus_plus);
|
|
|
|
if (cpp_runtime)
|
2011-05-04 11:43:18 +08:00
|
|
|
found_dynamic_type = cpp_runtime->GetDynamicTypeAndAddress (*m_parent, m_use_dynamic, class_type_or_name, dynamic_address);
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2011-04-16 08:01:13 +08:00
|
|
|
if (!found_dynamic_type)
|
|
|
|
{
|
|
|
|
LanguageRuntime *objc_runtime = process->GetLanguageRuntime (lldb::eLanguageTypeObjC);
|
|
|
|
if (objc_runtime)
|
2011-08-03 10:18:51 +08:00
|
|
|
found_dynamic_type = objc_runtime->GetDynamicTypeAndAddress (*m_parent, m_use_dynamic, class_type_or_name, dynamic_address);
|
2011-04-16 08:01:13 +08:00
|
|
|
}
|
|
|
|
}
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2011-05-03 02:13:59 +08:00
|
|
|
// Getting the dynamic value may have run the program a bit, and so marked us as needing updating, but we really
|
|
|
|
// don't...
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2011-05-03 02:13:59 +08:00
|
|
|
m_update_point.SetUpdated();
|
2013-10-29 08:28:35 +08:00
|
|
|
|
2013-10-30 01:42:02 +08:00
|
|
|
if (found_dynamic_type)
|
|
|
|
{
|
|
|
|
if (class_type_or_name.HasType())
|
|
|
|
{
|
2014-11-01 02:07:44 +08:00
|
|
|
m_type_impl = TypeImpl(m_parent->GetClangType(),FixupTypeAndOrName(class_type_or_name, *m_parent).GetClangASTType());
|
2013-10-30 01:42:02 +08:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
m_type_impl.Clear();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
2013-10-29 08:28:35 +08:00
|
|
|
{
|
2013-10-30 01:42:02 +08:00
|
|
|
m_type_impl.Clear();
|
2013-10-29 08:28:35 +08:00
|
|
|
}
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2011-04-16 08:01:13 +08:00
|
|
|
// If we don't have a dynamic type, then make ourselves just a echo of our parent.
|
|
|
|
// Or we could return false, and make ourselves an echo of our parent?
|
|
|
|
if (!found_dynamic_type)
|
|
|
|
{
|
2013-01-23 09:17:27 +08:00
|
|
|
if (m_dynamic_type_info)
|
2012-11-28 07:50:00 +08:00
|
|
|
SetValueDidChange(true);
|
2012-11-28 07:28:32 +08:00
|
|
|
ClearDynamicTypeInformation();
|
2013-01-23 09:17:27 +08:00
|
|
|
m_dynamic_type_info.Clear();
|
2011-04-16 08:01:13 +08:00
|
|
|
m_value = m_parent->GetValue();
|
2013-07-12 06:46:58 +08:00
|
|
|
m_error = m_value.GetValueAsData (&exe_ctx, m_data, 0, GetModule().get());
|
2011-04-16 08:01:13 +08:00
|
|
|
return m_error.Success();
|
|
|
|
}
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2011-04-16 08:01:13 +08:00
|
|
|
Value old_value(m_value);
|
|
|
|
|
2013-03-28 07:08:40 +08:00
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_TYPES));
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2012-10-23 02:18:36 +08:00
|
|
|
bool has_changed_type = false;
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2013-01-23 09:17:27 +08:00
|
|
|
if (!m_dynamic_type_info)
|
2011-04-16 08:01:13 +08:00
|
|
|
{
|
2013-01-23 09:17:27 +08:00
|
|
|
m_dynamic_type_info = class_type_or_name;
|
2012-10-23 02:18:36 +08:00
|
|
|
has_changed_type = true;
|
2011-04-16 08:01:13 +08:00
|
|
|
}
|
2013-01-23 09:17:27 +08:00
|
|
|
else if (class_type_or_name != m_dynamic_type_info)
|
2011-04-16 08:01:13 +08:00
|
|
|
{
|
|
|
|
// We are another type, we need to tear down our children...
|
2013-01-23 09:17:27 +08:00
|
|
|
m_dynamic_type_info = class_type_or_name;
|
2011-04-16 08:01:13 +08:00
|
|
|
SetValueDidChange (true);
|
2012-10-23 02:18:36 +08:00
|
|
|
has_changed_type = true;
|
2011-04-16 08:01:13 +08:00
|
|
|
}
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2012-10-23 02:18:36 +08:00
|
|
|
if (has_changed_type)
|
|
|
|
ClearDynamicTypeInformation ();
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2011-04-16 08:01:13 +08:00
|
|
|
if (!m_address.IsValid() || m_address != dynamic_address)
|
|
|
|
{
|
|
|
|
if (m_address.IsValid())
|
|
|
|
SetValueDidChange (true);
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2011-04-16 08:01:13 +08:00
|
|
|
// We've moved, so we should be fine...
|
|
|
|
m_address = dynamic_address;
|
2012-02-17 15:49:44 +08:00
|
|
|
lldb::TargetSP target_sp (GetTargetSP());
|
|
|
|
lldb::addr_t load_address = m_address.GetLoadAddress(target_sp.get());
|
2011-04-16 08:01:13 +08:00
|
|
|
m_value.GetScalar() = load_address;
|
|
|
|
}
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2013-10-29 08:28:35 +08:00
|
|
|
m_dynamic_type_info = FixupTypeAndOrName(m_dynamic_type_info, *m_parent);
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2013-07-12 06:46:58 +08:00
|
|
|
//m_value.SetContext (Value::eContextTypeClangType, corrected_type);
|
2013-10-29 08:28:35 +08:00
|
|
|
m_value.SetClangType (m_dynamic_type_info.GetClangASTType());
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2011-04-16 08:01:13 +08:00
|
|
|
// Our address is the location of the dynamic type stored in memory. It isn't a load address,
|
|
|
|
// because we aren't pointing to the LOCATION that stores the pointer to us, we're pointing to us...
|
|
|
|
m_value.SetValueType(Value::eValueTypeScalar);
|
|
|
|
|
2012-10-23 02:18:36 +08:00
|
|
|
if (has_changed_type && log)
|
2014-04-04 12:06:10 +08:00
|
|
|
log->Printf("[%s %p] has a new dynamic type %s", GetName().GetCString(),
|
|
|
|
static_cast<void*>(this), GetTypeName().GetCString());
|
|
|
|
|
2013-01-23 09:17:27 +08:00
|
|
|
if (m_address.IsValid() && m_dynamic_type_info)
|
2011-04-16 08:01:13 +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 = m_value.GetValueAsData (&exe_ctx, m_data, 0, GetModule().get());
|
2011-04-16 08:01:13 +08:00
|
|
|
if (m_error.Success())
|
|
|
|
{
|
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())
|
2011-04-16 08:01:13 +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.
|
|
|
|
SetValueDidChange (m_value.GetValueType() != old_value.GetValueType() || m_value.GetScalar() != old_value.GetScalar());
|
|
|
|
}
|
|
|
|
|
|
|
|
SetValueIsValid (true);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2011-04-16 08:01:13 +08:00
|
|
|
// We get here if we've failed above...
|
|
|
|
SetValueIsValid (false);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
bool
|
|
|
|
ValueObjectDynamicValue::IsInScope ()
|
|
|
|
{
|
|
|
|
return m_parent->IsInScope();
|
|
|
|
}
|
|
|
|
|
2012-05-09 05:25:06 +08:00
|
|
|
bool
|
|
|
|
ValueObjectDynamicValue::SetValueFromCString (const char *value_str, Error& error)
|
|
|
|
{
|
|
|
|
if (!UpdateValueIfNeeded(false))
|
|
|
|
{
|
|
|
|
error.SetErrorString("unable to read value");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
uint64_t my_value = GetValueAsUnsigned(UINT64_MAX);
|
|
|
|
uint64_t parent_value = m_parent->GetValueAsUnsigned(UINT64_MAX);
|
|
|
|
|
|
|
|
if (my_value == UINT64_MAX || parent_value == UINT64_MAX)
|
|
|
|
{
|
|
|
|
error.SetErrorString("unable to read value");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// if we are at an offset from our parent, in order to set ourselves correctly we would need
|
|
|
|
// to change the new value so that it refers to the correct dynamic type. we choose not to deal
|
|
|
|
// with that - if anything more than a value overwrite is required, you should be using the
|
|
|
|
// expression parser instead of the value editing facility
|
|
|
|
if (my_value != parent_value)
|
|
|
|
{
|
|
|
|
// but NULL'ing out a value should always be allowed
|
|
|
|
if (strcmp(value_str,"0"))
|
|
|
|
{
|
|
|
|
error.SetErrorString("unable to modify dynamic value, use 'expression' command");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
bool ret_val = m_parent->SetValueFromCString(value_str,error);
|
|
|
|
SetNeedsUpdate();
|
|
|
|
return ret_val;
|
|
|
|
}
|
2013-04-13 09:21:23 +08:00
|
|
|
|
|
|
|
bool
|
|
|
|
ValueObjectDynamicValue::SetData (DataExtractor &data, Error &error)
|
|
|
|
{
|
|
|
|
if (!UpdateValueIfNeeded(false))
|
|
|
|
{
|
|
|
|
error.SetErrorString("unable to read value");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
uint64_t my_value = GetValueAsUnsigned(UINT64_MAX);
|
|
|
|
uint64_t parent_value = m_parent->GetValueAsUnsigned(UINT64_MAX);
|
|
|
|
|
|
|
|
if (my_value == UINT64_MAX || parent_value == UINT64_MAX)
|
|
|
|
{
|
|
|
|
error.SetErrorString("unable to read value");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// if we are at an offset from our parent, in order to set ourselves correctly we would need
|
|
|
|
// to change the new value so that it refers to the correct dynamic type. we choose not to deal
|
|
|
|
// with that - if anything more than a value overwrite is required, you should be using the
|
|
|
|
// expression parser instead of the value editing facility
|
|
|
|
if (my_value != parent_value)
|
|
|
|
{
|
|
|
|
// but NULL'ing out a value should always be allowed
|
|
|
|
lldb::offset_t offset = 0;
|
|
|
|
|
|
|
|
if (data.GetPointer(&offset) != 0)
|
|
|
|
{
|
|
|
|
error.SetErrorString("unable to modify dynamic value, use 'expression' command");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
bool ret_val = m_parent->SetData(data, error);
|
|
|
|
SetNeedsUpdate();
|
|
|
|
return ret_val;
|
|
|
|
}
|