2010-10-05 08:00:42 +08:00
|
|
|
//===-- ValueObjectConstResult.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/ValueObjectConstResult.h"
|
|
|
|
|
|
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
|
|
|
#include "lldb/Core/ValueObjectChild.h"
|
|
|
|
|
#include "lldb/Core/ValueObjectConstResultChild.h"
|
2010-10-05 08:00:42 +08:00
|
|
|
#include "lldb/Core/DataExtractor.h"
|
|
|
|
|
#include "lldb/Core/Module.h"
|
2012-07-07 09:22:45 +08:00
|
|
|
#include "lldb/Core/ValueObjectDynamicValue.h"
|
2010-10-05 08:00:42 +08:00
|
|
|
#include "lldb/Core/ValueObjectList.h"
|
|
|
|
|
|
|
|
|
|
#include "lldb/Symbol/ClangASTType.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/Target.h"
|
|
|
|
|
|
|
|
|
|
using namespace lldb;
|
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
|
2011-04-23 07:53:53 +08:00
|
|
|
ValueObjectSP
|
2013-07-12 06:46:58 +08:00
|
|
|
ValueObjectConstResult::Create (ExecutionContextScope *exe_scope,
|
|
|
|
|
ByteOrder byte_order,
|
|
|
|
|
uint32_t addr_byte_size,
|
|
|
|
|
lldb::addr_t address)
|
2011-04-23 07:53:53 +08:00
|
|
|
{
|
|
|
|
|
return (new ValueObjectConstResult (exe_scope,
|
|
|
|
|
byte_order,
|
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
|
|
|
addr_byte_size,
|
|
|
|
|
address))->GetSP();
|
2011-04-23 07:53:53 +08:00
|
|
|
}
|
|
|
|
|
|
2013-07-12 06:46:58 +08:00
|
|
|
ValueObjectConstResult::ValueObjectConstResult (ExecutionContextScope *exe_scope,
|
|
|
|
|
ByteOrder byte_order,
|
|
|
|
|
uint32_t addr_byte_size,
|
|
|
|
|
lldb::addr_t address) :
|
2011-03-31 08:19:25 +08:00
|
|
|
ValueObject (exe_scope),
|
2010-12-14 10:59:59 +08:00
|
|
|
m_type_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
|
|
|
m_byte_size (0),
|
|
|
|
|
m_impl(this, address)
|
2010-12-14 10:59:59 +08:00
|
|
|
{
|
|
|
|
|
SetIsConstant ();
|
|
|
|
|
SetValueIsValid(true);
|
|
|
|
|
m_data.SetByteOrder(byte_order);
|
|
|
|
|
m_data.SetAddressByteSize(addr_byte_size);
|
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(eAddressTypeLoad);
|
2010-12-14 10:59:59 +08:00
|
|
|
}
|
|
|
|
|
|
2011-04-23 07:53:53 +08:00
|
|
|
ValueObjectSP
|
|
|
|
|
ValueObjectConstResult::Create
|
|
|
|
|
(
|
|
|
|
|
ExecutionContextScope *exe_scope,
|
2013-07-12 06:46:58 +08:00
|
|
|
const ClangASTType &clang_type,
|
2011-04-23 07:53:53 +08:00
|
|
|
const ConstString &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
|
|
|
const DataExtractor &data,
|
|
|
|
|
lldb::addr_t address
|
2011-04-23 07:53:53 +08:00
|
|
|
)
|
|
|
|
|
{
|
|
|
|
|
return (new ValueObjectConstResult (exe_scope,
|
|
|
|
|
clang_type,
|
|
|
|
|
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
|
|
|
data,
|
|
|
|
|
address))->GetSP();
|
2011-04-23 07:53:53 +08:00
|
|
|
}
|
|
|
|
|
|
2013-07-12 06:46:58 +08:00
|
|
|
ValueObjectConstResult::ValueObjectConstResult (ExecutionContextScope *exe_scope,
|
|
|
|
|
const ClangASTType &clang_type,
|
|
|
|
|
const ConstString &name,
|
|
|
|
|
const DataExtractor &data,
|
|
|
|
|
lldb::addr_t address) :
|
2011-03-31 08:19:25 +08:00
|
|
|
ValueObject (exe_scope),
|
2010-12-14 10:59:59 +08:00
|
|
|
m_type_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
|
|
|
m_byte_size (0),
|
|
|
|
|
m_impl(this, address)
|
2010-12-14 10:59:59 +08:00
|
|
|
{
|
|
|
|
|
m_data = data;
|
2012-01-05 09:11:09 +08:00
|
|
|
|
|
|
|
|
if (!m_data.GetSharedDataBuffer())
|
|
|
|
|
{
|
|
|
|
|
DataBufferSP shared_data_buffer(new DataBufferHeap(data.GetDataStart(), data.GetByteSize()));
|
|
|
|
|
m_data.SetData(shared_data_buffer);
|
|
|
|
|
}
|
|
|
|
|
|
2010-12-14 10:59:59 +08:00
|
|
|
m_value.GetScalar() = (uintptr_t)m_data.GetDataStart();
|
|
|
|
|
m_value.SetValueType(Value::eValueTypeHostAddress);
|
2013-07-12 06:46:58 +08:00
|
|
|
m_value.SetClangType(clang_type);
|
2010-12-14 10:59:59 +08:00
|
|
|
m_name = name;
|
|
|
|
|
SetIsConstant ();
|
|
|
|
|
SetValueIsValid(true);
|
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(eAddressTypeLoad);
|
2010-12-14 10:59:59 +08:00
|
|
|
}
|
|
|
|
|
|
2011-04-23 07:53:53 +08:00
|
|
|
ValueObjectSP
|
2013-07-12 06:46:58 +08:00
|
|
|
ValueObjectConstResult::Create (ExecutionContextScope *exe_scope,
|
|
|
|
|
const ClangASTType &clang_type,
|
|
|
|
|
const ConstString &name,
|
|
|
|
|
const lldb::DataBufferSP &data_sp,
|
|
|
|
|
lldb::ByteOrder data_byte_order,
|
|
|
|
|
uint32_t data_addr_size,
|
|
|
|
|
lldb::addr_t address)
|
2011-04-23 07:53:53 +08:00
|
|
|
{
|
|
|
|
|
return (new ValueObjectConstResult (exe_scope,
|
|
|
|
|
clang_type,
|
|
|
|
|
name,
|
|
|
|
|
data_sp,
|
|
|
|
|
data_byte_order,
|
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
|
|
|
data_addr_size,
|
|
|
|
|
address))->GetSP();
|
2011-04-23 07:53:53 +08:00
|
|
|
}
|
|
|
|
|
|
2011-12-17 09:35:57 +08:00
|
|
|
ValueObjectSP
|
|
|
|
|
ValueObjectConstResult::Create (ExecutionContextScope *exe_scope,
|
2013-07-12 06:46:58 +08:00
|
|
|
Value &value,
|
2014-12-09 07:13:56 +08:00
|
|
|
const ConstString &name,
|
|
|
|
|
Module *module)
|
2011-12-17 09:35:57 +08:00
|
|
|
{
|
2014-12-09 07:13:56 +08:00
|
|
|
return (new ValueObjectConstResult (exe_scope, value, name, module))->GetSP();
|
2011-12-17 09:35:57 +08:00
|
|
|
}
|
|
|
|
|
|
2013-07-12 06:46:58 +08:00
|
|
|
ValueObjectConstResult::ValueObjectConstResult (ExecutionContextScope *exe_scope,
|
|
|
|
|
const ClangASTType &clang_type,
|
|
|
|
|
const ConstString &name,
|
|
|
|
|
const lldb::DataBufferSP &data_sp,
|
|
|
|
|
lldb::ByteOrder data_byte_order,
|
|
|
|
|
uint32_t data_addr_size,
|
|
|
|
|
lldb::addr_t address) :
|
2011-03-31 08:19:25 +08:00
|
|
|
ValueObject (exe_scope),
|
2010-12-14 10:59:59 +08:00
|
|
|
m_type_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
|
|
|
m_byte_size (0),
|
|
|
|
|
m_impl(this, address)
|
2010-10-05 08:00:42 +08:00
|
|
|
{
|
|
|
|
|
m_data.SetByteOrder(data_byte_order);
|
|
|
|
|
m_data.SetAddressByteSize(data_addr_size);
|
|
|
|
|
m_data.SetData(data_sp);
|
|
|
|
|
m_value.GetScalar() = (uintptr_t)data_sp->GetBytes();
|
|
|
|
|
m_value.SetValueType(Value::eValueTypeHostAddress);
|
2013-07-12 06:46:58 +08:00
|
|
|
//m_value.SetContext(Value::eContextTypeClangType, clang_type);
|
|
|
|
|
m_value.SetClangType (clang_type);
|
2010-10-05 08:00:42 +08:00
|
|
|
m_name = name;
|
2010-10-05 11:13:51 +08:00
|
|
|
SetIsConstant ();
|
2010-10-16 06:47:36 +08:00
|
|
|
SetValueIsValid(true);
|
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(eAddressTypeLoad);
|
2010-12-14 10:59:59 +08:00
|
|
|
}
|
|
|
|
|
|
2011-04-23 07:53:53 +08:00
|
|
|
ValueObjectSP
|
2013-07-12 06:46:58 +08:00
|
|
|
ValueObjectConstResult::Create (ExecutionContextScope *exe_scope,
|
|
|
|
|
const ClangASTType &clang_type,
|
|
|
|
|
const ConstString &name,
|
|
|
|
|
lldb::addr_t address,
|
|
|
|
|
AddressType address_type,
|
|
|
|
|
uint32_t addr_byte_size)
|
2011-04-23 07:53:53 +08:00
|
|
|
{
|
|
|
|
|
return (new ValueObjectConstResult (exe_scope,
|
|
|
|
|
clang_type,
|
|
|
|
|
name,
|
|
|
|
|
address,
|
|
|
|
|
address_type,
|
|
|
|
|
addr_byte_size))->GetSP();
|
|
|
|
|
}
|
|
|
|
|
|
2013-07-12 06:46:58 +08:00
|
|
|
ValueObjectConstResult::ValueObjectConstResult (ExecutionContextScope *exe_scope,
|
|
|
|
|
const ClangASTType &clang_type,
|
|
|
|
|
const ConstString &name,
|
|
|
|
|
lldb::addr_t address,
|
|
|
|
|
AddressType address_type,
|
|
|
|
|
uint32_t addr_byte_size) :
|
2011-03-31 08:19:25 +08:00
|
|
|
ValueObject (exe_scope),
|
2010-12-14 10:59:59 +08:00
|
|
|
m_type_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
|
|
|
m_byte_size (0),
|
|
|
|
|
m_impl(this, address)
|
2010-12-14 10:59:59 +08:00
|
|
|
{
|
|
|
|
|
m_value.GetScalar() = address;
|
|
|
|
|
m_data.SetAddressByteSize(addr_byte_size);
|
|
|
|
|
m_value.GetScalar().GetData (m_data, addr_byte_size);
|
|
|
|
|
//m_value.SetValueType(Value::eValueTypeHostAddress);
|
|
|
|
|
switch (address_type)
|
|
|
|
|
{
|
|
|
|
|
case eAddressTypeInvalid: m_value.SetValueType(Value::eValueTypeScalar); break;
|
|
|
|
|
case eAddressTypeFile: m_value.SetValueType(Value::eValueTypeFileAddress); break;
|
|
|
|
|
case eAddressTypeLoad: m_value.SetValueType(Value::eValueTypeLoadAddress); break;
|
|
|
|
|
case eAddressTypeHost: m_value.SetValueType(Value::eValueTypeHostAddress); break;
|
|
|
|
|
}
|
2013-07-12 06:46:58 +08:00
|
|
|
// m_value.SetContext(Value::eContextTypeClangType, clang_type);
|
|
|
|
|
m_value.SetClangType (clang_type);
|
2010-12-14 10:59:59 +08:00
|
|
|
m_name = name;
|
|
|
|
|
SetIsConstant ();
|
|
|
|
|
SetValueIsValid(true);
|
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(eAddressTypeLoad);
|
2010-10-05 11:13:51 +08:00
|
|
|
}
|
|
|
|
|
|
2011-04-23 07:53:53 +08:00
|
|
|
ValueObjectSP
|
|
|
|
|
ValueObjectConstResult::Create
|
|
|
|
|
(
|
|
|
|
|
ExecutionContextScope *exe_scope,
|
|
|
|
|
const Error& error
|
|
|
|
|
)
|
|
|
|
|
{
|
|
|
|
|
return (new ValueObjectConstResult (exe_scope,
|
|
|
|
|
error))->GetSP();
|
|
|
|
|
}
|
|
|
|
|
|
2013-07-12 06:46:58 +08:00
|
|
|
ValueObjectConstResult::ValueObjectConstResult (ExecutionContextScope *exe_scope,
|
|
|
|
|
const Error& error) :
|
2011-03-31 08:19:25 +08:00
|
|
|
ValueObject (exe_scope),
|
2010-12-14 10:59:59 +08:00
|
|
|
m_type_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
|
|
|
m_byte_size (0),
|
|
|
|
|
m_impl(this)
|
2010-10-05 11:13:51 +08:00
|
|
|
{
|
|
|
|
|
m_error = error;
|
|
|
|
|
SetIsConstant ();
|
2010-10-05 08:00:42 +08:00
|
|
|
}
|
|
|
|
|
|
2013-07-12 06:46:58 +08:00
|
|
|
ValueObjectConstResult::ValueObjectConstResult (ExecutionContextScope *exe_scope,
|
|
|
|
|
const Value &value,
|
2014-12-09 07:13:56 +08:00
|
|
|
const ConstString &name,
|
|
|
|
|
Module *module) :
|
2011-12-17 09:35:57 +08:00
|
|
|
ValueObject (exe_scope),
|
|
|
|
|
m_type_name (),
|
|
|
|
|
m_byte_size (0),
|
|
|
|
|
m_impl(this)
|
|
|
|
|
{
|
|
|
|
|
m_value = value;
|
2014-10-16 05:38:32 +08:00
|
|
|
m_name = name;
|
2014-12-09 07:13:56 +08:00
|
|
|
ExecutionContext exe_ctx;
|
|
|
|
|
exe_scope->CalculateExecutionContext(exe_ctx);
|
|
|
|
|
m_error = m_value.GetValueAsData(&exe_ctx, m_data, 0, module);
|
2011-12-17 09:35:57 +08:00
|
|
|
}
|
|
|
|
|
|
2010-10-05 08:00:42 +08:00
|
|
|
ValueObjectConstResult::~ValueObjectConstResult()
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2013-07-12 06:46:58 +08:00
|
|
|
ClangASTType
|
2012-02-23 07:57:45 +08:00
|
|
|
ValueObjectConstResult::GetClangTypeImpl()
|
2010-10-05 08:00:42 +08:00
|
|
|
{
|
|
|
|
|
return m_value.GetClangType();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
lldb::ValueType
|
|
|
|
|
ValueObjectConstResult::GetValueType() const
|
|
|
|
|
{
|
|
|
|
|
return eValueTypeConstResult;
|
|
|
|
|
}
|
|
|
|
|
|
2013-03-15 02:31:44 +08:00
|
|
|
uint64_t
|
2010-10-05 08:00:42 +08:00
|
|
|
ValueObjectConstResult::GetByteSize()
|
|
|
|
|
{
|
2015-01-28 09:09:45 +08:00
|
|
|
ExecutionContext exe_ctx(GetExecutionContextRef());
|
|
|
|
|
|
2010-12-14 10:59:59 +08:00
|
|
|
if (m_byte_size == 0)
|
2015-02-12 08:34:25 +08:00
|
|
|
SetByteSize(GetClangType().GetByteSize(exe_ctx.GetBestExecutionContextScope()));
|
2010-12-14 10:59:59 +08:00
|
|
|
return m_byte_size;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
ValueObjectConstResult::SetByteSize (size_t size)
|
|
|
|
|
{
|
|
|
|
|
m_byte_size = size;
|
2010-10-05 08:00:42 +08:00
|
|
|
}
|
|
|
|
|
|
2013-01-26 02:06:21 +08:00
|
|
|
size_t
|
2010-10-05 08:00:42 +08:00
|
|
|
ValueObjectConstResult::CalculateNumChildren()
|
|
|
|
|
{
|
2013-07-12 06:46:58 +08:00
|
|
|
return GetClangType().GetNumChildren (true);
|
2010-10-05 08:00:42 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ConstString
|
|
|
|
|
ValueObjectConstResult::GetTypeName()
|
|
|
|
|
{
|
|
|
|
|
if (m_type_name.IsEmpty())
|
2013-07-12 06:46:58 +08:00
|
|
|
m_type_name = GetClangType().GetConstTypeName ();
|
2010-10-05 08:00:42 +08:00
|
|
|
return m_type_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
|
|
|
|
|
ValueObjectConstResult::GetDisplayTypeName()
|
|
|
|
|
{
|
|
|
|
|
return GetClangType().GetDisplayTypeName();
|
|
|
|
|
}
|
|
|
|
|
|
2011-03-31 08:19:25 +08:00
|
|
|
bool
|
|
|
|
|
ValueObjectConstResult::UpdateValue ()
|
2010-10-05 08:00:42 +08:00
|
|
|
{
|
|
|
|
|
// Const value is always valid
|
|
|
|
|
SetValueIsValid (true);
|
2011-03-31 08:19:25 +08:00
|
|
|
return true;
|
2010-10-05 08:00:42 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
bool
|
2011-03-31 08:19:25 +08:00
|
|
|
ValueObjectConstResult::IsInScope ()
|
2010-10-05 08:00:42 +08:00
|
|
|
{
|
|
|
|
|
// A const result value is always in scope since it serializes all
|
|
|
|
|
// information needed to contain the constant value.
|
|
|
|
|
return true;
|
|
|
|
|
}
|
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
|
|
|
|
|
|
|
|
lldb::ValueObjectSP
|
|
|
|
|
ValueObjectConstResult::Dereference (Error &error)
|
|
|
|
|
{
|
|
|
|
|
return m_impl.Dereference(error);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
lldb::ValueObjectSP
|
|
|
|
|
ValueObjectConstResult::GetSyntheticChildAtOffset(uint32_t offset, const ClangASTType& type, bool can_create)
|
|
|
|
|
{
|
|
|
|
|
return m_impl.GetSyntheticChildAtOffset(offset, type, can_create);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
lldb::ValueObjectSP
|
|
|
|
|
ValueObjectConstResult::AddressOf (Error &error)
|
|
|
|
|
{
|
|
|
|
|
return m_impl.AddressOf(error);
|
|
|
|
|
}
|
|
|
|
|
|
2011-12-17 07:04:52 +08:00
|
|
|
lldb::addr_t
|
|
|
|
|
ValueObjectConstResult::GetAddressOf (bool scalar_is_load_address,
|
|
|
|
|
AddressType *address_type)
|
|
|
|
|
{
|
|
|
|
|
return m_impl.GetAddressOf(scalar_is_load_address, address_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
|
|
|
ValueObject *
|
2013-01-26 02:06:21 +08:00
|
|
|
ValueObjectConstResult::CreateChildAtIndex (size_t idx, bool synthetic_array_member, int32_t synthetic_index)
|
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
|
|
|
{
|
|
|
|
|
return m_impl.CreateChildAtIndex(idx, synthetic_array_member, synthetic_index);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
size_t
|
|
|
|
|
ValueObjectConstResult::GetPointeeData (DataExtractor& data,
|
|
|
|
|
uint32_t item_idx,
|
|
|
|
|
uint32_t item_count)
|
|
|
|
|
{
|
|
|
|
|
return m_impl.GetPointeeData(data, item_idx, item_count);
|
|
|
|
|
}
|
2012-07-07 09:22:45 +08:00
|
|
|
|
|
|
|
|
lldb::ValueObjectSP
|
|
|
|
|
ValueObjectConstResult::GetDynamicValue (lldb::DynamicValueType use_dynamic)
|
|
|
|
|
{
|
|
|
|
|
// Always recalculate dynamic values for const results as the memory that
|
|
|
|
|
// they might point to might have changed at any time.
|
|
|
|
|
if (use_dynamic != eNoDynamicValues)
|
|
|
|
|
{
|
|
|
|
|
if (!IsDynamic())
|
|
|
|
|
{
|
|
|
|
|
ExecutionContext exe_ctx (GetExecutionContextRef());
|
|
|
|
|
Process *process = exe_ctx.GetProcessPtr();
|
|
|
|
|
if (process && process->IsPossibleDynamicValue(*this))
|
|
|
|
|
m_dynamic_value = new ValueObjectDynamicValue (*this, use_dynamic);
|
|
|
|
|
}
|
|
|
|
|
if (m_dynamic_value)
|
|
|
|
|
return m_dynamic_value->GetSP();
|
|
|
|
|
}
|
|
|
|
|
return ValueObjectSP();
|
|
|
|
|
}
|
|
|
|
|
|
2014-11-07 05:23:20 +08:00
|
|
|
lldb::LanguageType
|
|
|
|
|
ValueObjectConstResult::GetPreferredDisplayLanguage ()
|
|
|
|
|
{
|
|
|
|
|
return lldb::eLanguageTypeUnknown;
|
|
|
|
|
}
|