intel/llvm
1
0
Fork 0
mirror of https://github.com/intel/llvm.git synced 2026-01-18 16:50:51 +08:00
Code Issues Packages Projects Releases Wiki Activity

This is a refinement on 96601ec28b. The intent of that change was to do the same work for the computation of the locations of the children of ValueObjectVariable as was done for the root ValueObjectVariable. This original patch did that by moving the computation from ValueObjectVariable to ValueObject. That fixed the problem but caused a handful of swift-lldb testsuite failures and a crash or two.

Browse Source 
The problem is that synthetic value objects can sometimes represent objects in target memory, and other times they might be made up wholly in lldb memory, with pointers from one synthetic object to another, and so the ValueObjectVariable computation was not appropriate.

This patch delegates the computation to the root of the ValueObject in question. That solves the problem for ValueObjectVariable while not messing up the computation for ValueObjectConstResult or ValueObjectSynthetic.

Differential Revision: https://reviews.llvm.org/D83450
This commit is contained in:
Jim Ingham
2020-07-10 11:10:56 -07:00
parent 8c8a2fd1f0
commit e337350be9
4 changed files with 63 additions and 53 deletions
Download Patch File Download Diff File Expand all files Collapse all files

52
lldb/source/Core/ValueObject.cpp
View File

@@ -140,58 +140,6 @@ ValueObject::ValueObject(ExecutionContextScope *exe_scope,
// Destructor
ValueObject::~ValueObject() {}
void ValueObject::UpdateChildrenAddressType() {
Value::ValueType value_type = m_value.GetValueType();
ExecutionContext exe_ctx(GetExecutionContextRef());
Process *process = exe_ctx.GetProcessPtr();
const bool process_is_alive = process && process->IsAlive();
const uint32_t type_info = GetCompilerType().GetTypeInfo();
const bool is_pointer_or_ref =
(type_info & (lldb::eTypeIsPointer | lldb::eTypeIsReference)) != 0;
switch (value_type) {
case Value::eValueTypeFileAddress:
// If this type is a pointer, then its children will be considered load
// addresses if the pointer or reference is dereferenced, but only if
// the process is alive.
//
// There could be global variables like in the following code:
// struct LinkedListNode { Foo* foo; LinkedListNode* next; };
// Foo g_foo1;
// Foo g_foo2;
// LinkedListNode g_second_node = { &g_foo2, NULL };
// LinkedListNode g_first_node = { &g_foo1, &g_second_node };
//
// When we aren't running, we should be able to look at these variables
// using the "target variable" command. Children of the "g_first_node"
// always will be of the same address type as the parent. But children
// of the "next" member of LinkedListNode will become load addresses if
// we have a live process, or remain a file address if it was a file
// address.
if (process_is_alive && is_pointer_or_ref)
SetAddressTypeOfChildren(eAddressTypeLoad);
else
SetAddressTypeOfChildren(eAddressTypeFile);
break;
case Value::eValueTypeHostAddress:
// Same as above for load addresses, except children of pointer or refs
// are always load addresses. Host addresses are used to store freeze
// dried variables. If this type is a struct, the entire struct
// contents will be copied into the heap of the
// LLDB process, but we do not currently follow any pointers.
if (is_pointer_or_ref)
SetAddressTypeOfChildren(eAddressTypeLoad);
else
SetAddressTypeOfChildren(eAddressTypeHost);
break;
case Value::eValueTypeLoadAddress:
case Value::eValueTypeScalar:
case Value::eValueTypeVector:
SetAddressTypeOfChildren(eAddressTypeLoad);
break;
}
}
bool ValueObject::UpdateValueIfNeeded(bool update_format) {
bool did_change_formats = false;