llvm-project/lldb/source/Core/ValueObjectVariable.cpp

205 lines
6.3 KiB
C++
Raw Normal View History

//===-- ValueObjectVariable.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/ValueObjectVariable.h"
// C Includes
// C++ Includes
// Other libraries and framework includes
// Project includes
#include "lldb/Core/Module.h"
#include "lldb/Core/ValueObjectList.h"
#include "lldb/Core/Value.h"
#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/Process.h"
#include "lldb/Target/RegisterContext.h"
#include "lldb/Target/Target.h"
#include "lldb/Target/Thread.h"
using namespace lldb_private;
ValueObjectVariable::ValueObjectVariable (const lldb::VariableSP &var_sp) :
Fixed an expression parsing issue where if you were stopped somewhere without debug information and you evaluated an expression, a crash would occur as a result of an unchecked pointer. Added the ability to get the expression path for a ValueObject. For a rectangle point child "x" the expression path would be something like: "rect.top_left.x". This will allow GUI and command lines to get ahold of the expression path for a value object without having to explicitly know about the hierarchy. This means the ValueObject base class now has a "ValueObject *m_parent;" member. All ValueObject subclasses now correctly track their lineage and are able to provide value expression paths as well. Added a new "--flat" option to the "frame variable" to allow for flat variable output. An example of the current and new outputs: (lldb) frame variable argc = 1 argv = 0x00007fff5fbffe80 pt = { x = 2 y = 3 } rect = { bottom_left = { x = 1 y = 2 } top_right = { x = 3 y = 4 } } (lldb) frame variable --flat argc = 1 argv = 0x00007fff5fbffe80 pt.x = 2 pt.y = 3 rect.bottom_left.x = 1 rect.bottom_left.y = 2 rect.top_right.x = 3 rect.top_right.y = 4 As you can see when there is a lot of hierarchy it can help flatten things out. Also if you want to use a member in an expression, you can copy the text from the "--flat" output and not have to piece it together manually. This can help when you want to use parts of the STL in expressions: (lldb) frame variable --flat argc = 1 argv = 0x00007fff5fbffea8 hello_world._M_dataplus._M_p = 0x0000000000000000 (lldb) expr hello_world._M_dataplus._M_p[0] == '\0' llvm-svn: 116532
2010-10-15 06:52:14 +08:00
ValueObject(NULL),
m_variable_sp(var_sp)
{
// Do not attempt to construct one of these objects with no variable!
assert (m_variable_sp.get() != NULL);
m_name = var_sp->GetName();
}
ValueObjectVariable::~ValueObjectVariable()
{
}
void *
ValueObjectVariable::GetClangType ()
{
Type *var_type = m_variable_sp->GetType();
if (var_type)
return var_type->GetClangType();
return NULL;
}
ConstString
ValueObjectVariable::GetTypeName()
{
Type * var_type = m_variable_sp->GetType();
if (var_type)
return var_type->GetName();
ConstString empty_type_name;
return empty_type_name;
}
uint32_t
ValueObjectVariable::CalculateNumChildren()
{
Type *var_type = m_variable_sp->GetType();
if (var_type)
return var_type->GetNumChildren(true);
return 0;
}
clang::ASTContext *
ValueObjectVariable::GetClangAST ()
{
return m_variable_sp->GetType()->GetClangAST();
}
size_t
ValueObjectVariable::GetByteSize()
{
return m_variable_sp->GetType()->GetByteSize();
}
lldb::ValueType
ValueObjectVariable::GetValueType() const
{
if (m_variable_sp)
return m_variable_sp->GetScope();
return lldb::eValueTypeInvalid;
}
void
ValueObjectVariable::UpdateValue (ExecutionContextScope *exe_scope)
{
SetValueIsValid (false);
m_error.Clear();
Variable *variable = m_variable_sp.get();
DWARFExpression &expr = variable->LocationExpression();
Looking at some of the test suite failures in DWARF in .o files with the debug map showed that the location lists in the .o files needed some refactoring in order to work. The case that was failing was where a function that was in the "__TEXT.__textcoal_nt" in the .o file, and in the "__TEXT.__text" section in the main executable. This made symbol lookup fail due to the way we were finding a real address in the debug map which was by finding the section that the function was in in the .o file and trying to find this in the main executable. Now the section list supports finding a linked address in a section or any child sections. After fixing this, we ran into issue that were due to DWARF and how it represents locations lists. DWARF makes a list of address ranges and expressions that go along with those address ranges. The location addresses are expressed in terms of a compile unit address + offset. This works fine as long as nothing moves around. When stuff moves around and offsets change between the remapped compile unit base address and the new function address, then we can run into trouble. To deal with this, we now store supply a location list slide amount to any location list expressions that will allow us to make the location list addresses into zero based offsets from the object that owns the location list (always a function in our case). With these fixes we can now re-link random address ranges inside the debugger for use with our DWARF + debug map, incremental linking, and more. Another issue that arose when doing the DWARF in the .o files was that GCC 4.2 emits a ".debug_aranges" that only mentions functions that are externally visible. This makes .debug_aranges useless to us and we now generate a real address range lookup table in the DWARF parser at the same time as we index the name tables (that are needed because .debug_pubnames is just as useless). llvm-gcc doesn't generate a .debug_aranges section, though this could be fixed, we aren't going to rely upon it. Renamed a bunch of "UINT_MAX" to "UINT32_MAX". llvm-svn: 113829
2010-09-14 10:20:48 +08:00
lldb::addr_t loclist_base_load_addr = LLDB_INVALID_ADDRESS;
ExecutionContext exe_ctx (exe_scope);
if (exe_ctx.process)
{
m_data.SetByteOrder(exe_ctx.process->GetByteOrder());
m_data.SetAddressByteSize(exe_ctx.process->GetAddressByteSize());
}
Looking at some of the test suite failures in DWARF in .o files with the debug map showed that the location lists in the .o files needed some refactoring in order to work. The case that was failing was where a function that was in the "__TEXT.__textcoal_nt" in the .o file, and in the "__TEXT.__text" section in the main executable. This made symbol lookup fail due to the way we were finding a real address in the debug map which was by finding the section that the function was in in the .o file and trying to find this in the main executable. Now the section list supports finding a linked address in a section or any child sections. After fixing this, we ran into issue that were due to DWARF and how it represents locations lists. DWARF makes a list of address ranges and expressions that go along with those address ranges. The location addresses are expressed in terms of a compile unit address + offset. This works fine as long as nothing moves around. When stuff moves around and offsets change between the remapped compile unit base address and the new function address, then we can run into trouble. To deal with this, we now store supply a location list slide amount to any location list expressions that will allow us to make the location list addresses into zero based offsets from the object that owns the location list (always a function in our case). With these fixes we can now re-link random address ranges inside the debugger for use with our DWARF + debug map, incremental linking, and more. Another issue that arose when doing the DWARF in the .o files was that GCC 4.2 emits a ".debug_aranges" that only mentions functions that are externally visible. This makes .debug_aranges useless to us and we now generate a real address range lookup table in the DWARF parser at the same time as we index the name tables (that are needed because .debug_pubnames is just as useless). llvm-gcc doesn't generate a .debug_aranges section, though this could be fixed, we aren't going to rely upon it. Renamed a bunch of "UINT_MAX" to "UINT32_MAX". llvm-svn: 113829
2010-09-14 10:20:48 +08:00
if (expr.IsLocationList())
{
SymbolContext sc;
variable->CalculateSymbolContext (&sc);
if (sc.function)
loclist_base_load_addr = sc.function->GetAddressRange().GetBaseAddress().GetLoadAddress (exe_ctx.target);
Looking at some of the test suite failures in DWARF in .o files with the debug map showed that the location lists in the .o files needed some refactoring in order to work. The case that was failing was where a function that was in the "__TEXT.__textcoal_nt" in the .o file, and in the "__TEXT.__text" section in the main executable. This made symbol lookup fail due to the way we were finding a real address in the debug map which was by finding the section that the function was in in the .o file and trying to find this in the main executable. Now the section list supports finding a linked address in a section or any child sections. After fixing this, we ran into issue that were due to DWARF and how it represents locations lists. DWARF makes a list of address ranges and expressions that go along with those address ranges. The location addresses are expressed in terms of a compile unit address + offset. This works fine as long as nothing moves around. When stuff moves around and offsets change between the remapped compile unit base address and the new function address, then we can run into trouble. To deal with this, we now store supply a location list slide amount to any location list expressions that will allow us to make the location list addresses into zero based offsets from the object that owns the location list (always a function in our case). With these fixes we can now re-link random address ranges inside the debugger for use with our DWARF + debug map, incremental linking, and more. Another issue that arose when doing the DWARF in the .o files was that GCC 4.2 emits a ".debug_aranges" that only mentions functions that are externally visible. This makes .debug_aranges useless to us and we now generate a real address range lookup table in the DWARF parser at the same time as we index the name tables (that are needed because .debug_pubnames is just as useless). llvm-gcc doesn't generate a .debug_aranges section, though this could be fixed, we aren't going to rely upon it. Renamed a bunch of "UINT_MAX" to "UINT32_MAX". llvm-svn: 113829
2010-09-14 10:20:48 +08:00
}
Value old_value(m_value);
if (expr.Evaluate (&exe_ctx, GetClangAST(), NULL, loclist_base_load_addr, NULL, m_value, &m_error))
{
m_value.SetContext(Value::eContextTypeVariable, variable);
Value::ValueType value_type = m_value.GetValueType();
switch (value_type)
{
default:
assert(!"Unhandled expression result value kind...");
break;
case Value::eValueTypeScalar:
// The variable value is in the Scalar value inside the m_value.
// We can point our m_data right to it.
m_error = m_value.GetValueAsData (&exe_ctx, GetClangAST(), m_data, 0);
break;
case Value::eValueTypeFileAddress:
case Value::eValueTypeLoadAddress:
case Value::eValueTypeHostAddress:
// The DWARF expression result was an address in the inferior
// process. If this variable is an aggregate type, we just need
// the address as the main value as all child variable objects
// will rely upon this location and add an offset and then read
// their own values as needed. If this variable is a simple
// type, we read all data for it into m_data.
// Make sure this type has a value before we try and read it
// If we have a file address, convert it to a load address if we can.
if (value_type == Value::eValueTypeFileAddress && exe_ctx.process)
{
lldb::addr_t file_addr = m_value.GetScalar().ULongLong(LLDB_INVALID_ADDRESS);
if (file_addr != LLDB_INVALID_ADDRESS)
{
SymbolContext var_sc;
variable->CalculateSymbolContext(&var_sc);
if (var_sc.module_sp)
{
ObjectFile *objfile = var_sc.module_sp->GetObjectFile();
if (objfile)
{
Address so_addr(file_addr, objfile->GetSectionList());
lldb::addr_t load_addr = so_addr.GetLoadAddress (exe_ctx.target);
if (load_addr != LLDB_INVALID_ADDRESS)
{
m_value.SetValueType(Value::eValueTypeLoadAddress);
m_value.GetScalar() = load_addr;
}
}
}
}
}
if (ClangASTContext::IsAggregateType (GetClangType()))
{
// 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 (value_type != old_value.GetValueType() || m_value.GetScalar() != old_value.GetScalar());
}
else
{
// Copy the Value and set the context to use our Variable
// so it can extract read its value into m_data appropriately
Value value(m_value);
value.SetContext(Value::eContextTypeVariable, variable);
m_error = value.GetValueAsData(&exe_ctx, GetClangAST(), m_data, 0);
}
break;
}
SetValueIsValid (m_error.Success());
}
}
bool
ValueObjectVariable::IsInScope (StackFrame *frame)
{
return m_variable_sp->IsInScope (frame);
}