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
|
|
|
//===-- SBData.cpp ----------------------------------------------*- C++ -*-===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2018-11-12 07:16:43 +08:00
|
|
|
#include <inttypes.h>
|
2014-04-19 11:09:28 +08:00
|
|
|
|
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/API/SBData.h"
|
|
|
|
#include "lldb/API/SBError.h"
|
|
|
|
#include "lldb/API/SBStream.h"
|
|
|
|
|
2017-03-04 04:57:05 +08:00
|
|
|
#include "lldb/Core/DumpDataExtractor.h"
|
2017-03-04 09:30:05 +08:00
|
|
|
#include "lldb/Utility/DataBufferHeap.h"
|
|
|
|
#include "lldb/Utility/DataExtractor.h"
|
2017-03-04 04:56:28 +08:00
|
|
|
#include "lldb/Utility/Log.h"
|
2017-02-03 05:39:50 +08:00
|
|
|
#include "lldb/Utility/Stream.h"
|
2011-11-13 14:57:31 +08:00
|
|
|
|
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
|
|
|
using namespace lldb;
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
SBData::SBData() : m_opaque_sp(new DataExtractor()) {}
|
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
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
SBData::SBData(const lldb::DataExtractorSP &data_sp) : m_opaque_sp(data_sp) {}
|
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
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
SBData::SBData(const SBData &rhs) : m_opaque_sp(rhs.m_opaque_sp) {}
|
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
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
const SBData &SBData::operator=(const SBData &rhs) {
|
|
|
|
if (this != &rhs)
|
|
|
|
m_opaque_sp = rhs.m_opaque_sp;
|
|
|
|
return *this;
|
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
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
SBData::~SBData() {}
|
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
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
void SBData::SetOpaque(const lldb::DataExtractorSP &data_sp) {
|
|
|
|
m_opaque_sp = data_sp;
|
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
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
lldb_private::DataExtractor *SBData::get() const { return m_opaque_sp.get(); }
|
|
|
|
|
|
|
|
lldb_private::DataExtractor *SBData::operator->() const {
|
|
|
|
return m_opaque_sp.operator->();
|
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
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
lldb::DataExtractorSP &SBData::operator*() { return m_opaque_sp; }
|
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
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
const lldb::DataExtractorSP &SBData::operator*() const { return m_opaque_sp; }
|
|
|
|
|
|
|
|
bool SBData::IsValid() { return m_opaque_sp.get() != NULL; }
|
|
|
|
|
|
|
|
uint8_t SBData::GetAddressByteSize() {
|
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
|
|
|
|
uint8_t value = 0;
|
|
|
|
if (m_opaque_sp.get())
|
|
|
|
value = m_opaque_sp->GetAddressByteSize();
|
|
|
|
if (log)
|
|
|
|
log->Printf("SBData::GetAddressByteSize () => "
|
|
|
|
"(%i)",
|
|
|
|
value);
|
|
|
|
return value;
|
|
|
|
}
|
|
|
|
|
|
|
|
void SBData::SetAddressByteSize(uint8_t addr_byte_size) {
|
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
|
|
|
|
if (m_opaque_sp.get())
|
|
|
|
m_opaque_sp->SetAddressByteSize(addr_byte_size);
|
|
|
|
if (log)
|
|
|
|
log->Printf("SBData::SetAddressByteSize (%i)", addr_byte_size);
|
|
|
|
}
|
|
|
|
|
|
|
|
void SBData::Clear() {
|
|
|
|
if (m_opaque_sp.get())
|
|
|
|
m_opaque_sp->Clear();
|
|
|
|
}
|
|
|
|
|
|
|
|
size_t SBData::GetByteSize() {
|
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
|
|
|
|
size_t value = 0;
|
|
|
|
if (m_opaque_sp.get())
|
|
|
|
value = m_opaque_sp->GetByteSize();
|
|
|
|
if (log)
|
|
|
|
log->Printf("SBData::GetByteSize () => "
|
|
|
|
"( %" PRIu64 " )",
|
|
|
|
(uint64_t)value);
|
|
|
|
return value;
|
|
|
|
}
|
|
|
|
|
|
|
|
lldb::ByteOrder SBData::GetByteOrder() {
|
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
|
|
|
|
lldb::ByteOrder value = eByteOrderInvalid;
|
|
|
|
if (m_opaque_sp.get())
|
|
|
|
value = m_opaque_sp->GetByteOrder();
|
|
|
|
if (log)
|
|
|
|
log->Printf("SBData::GetByteOrder () => "
|
|
|
|
"(%i)",
|
|
|
|
value);
|
|
|
|
return value;
|
|
|
|
}
|
|
|
|
|
|
|
|
void SBData::SetByteOrder(lldb::ByteOrder endian) {
|
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
|
|
|
|
if (m_opaque_sp.get())
|
|
|
|
m_opaque_sp->SetByteOrder(endian);
|
|
|
|
if (log)
|
|
|
|
log->Printf("SBData::GetByteOrder (%i)", endian);
|
|
|
|
}
|
|
|
|
|
|
|
|
float SBData::GetFloat(lldb::SBError &error, lldb::offset_t offset) {
|
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
|
|
|
|
float value = 0;
|
|
|
|
if (!m_opaque_sp.get()) {
|
|
|
|
error.SetErrorString("no value to read from");
|
|
|
|
} else {
|
|
|
|
uint32_t old_offset = offset;
|
|
|
|
value = m_opaque_sp->GetFloat(&offset);
|
|
|
|
if (offset == old_offset)
|
|
|
|
error.SetErrorString("unable to read data");
|
|
|
|
}
|
|
|
|
if (log)
|
|
|
|
log->Printf("SBData::GetFloat (error=%p,offset=%" PRIu64 ") => (%f)",
|
|
|
|
static_cast<void *>(error.get()), offset, value);
|
|
|
|
return value;
|
|
|
|
}
|
|
|
|
|
|
|
|
double SBData::GetDouble(lldb::SBError &error, lldb::offset_t offset) {
|
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
|
|
|
|
double value = 0;
|
|
|
|
if (!m_opaque_sp.get()) {
|
|
|
|
error.SetErrorString("no value to read from");
|
|
|
|
} else {
|
|
|
|
uint32_t old_offset = offset;
|
|
|
|
value = m_opaque_sp->GetDouble(&offset);
|
|
|
|
if (offset == old_offset)
|
|
|
|
error.SetErrorString("unable to read data");
|
|
|
|
}
|
|
|
|
if (log)
|
|
|
|
log->Printf("SBData::GetDouble (error=%p,offset=%" PRIu64 ") => "
|
|
|
|
"(%f)",
|
|
|
|
static_cast<void *>(error.get()), offset, value);
|
|
|
|
return value;
|
|
|
|
}
|
|
|
|
|
|
|
|
long double SBData::GetLongDouble(lldb::SBError &error, lldb::offset_t offset) {
|
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
|
|
|
|
long double value = 0;
|
|
|
|
if (!m_opaque_sp.get()) {
|
|
|
|
error.SetErrorString("no value to read from");
|
|
|
|
} else {
|
|
|
|
uint32_t old_offset = offset;
|
|
|
|
value = m_opaque_sp->GetLongDouble(&offset);
|
|
|
|
if (offset == old_offset)
|
|
|
|
error.SetErrorString("unable to read data");
|
|
|
|
}
|
|
|
|
if (log)
|
|
|
|
log->Printf("SBData::GetLongDouble (error=%p,offset=%" PRIu64 ") => "
|
|
|
|
"(%Lf)",
|
|
|
|
static_cast<void *>(error.get()), offset, value);
|
|
|
|
return value;
|
|
|
|
}
|
|
|
|
|
|
|
|
lldb::addr_t SBData::GetAddress(lldb::SBError &error, lldb::offset_t offset) {
|
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
|
|
|
|
lldb::addr_t value = 0;
|
|
|
|
if (!m_opaque_sp.get()) {
|
|
|
|
error.SetErrorString("no value to read from");
|
|
|
|
} else {
|
|
|
|
uint32_t old_offset = offset;
|
|
|
|
value = m_opaque_sp->GetAddress(&offset);
|
|
|
|
if (offset == old_offset)
|
|
|
|
error.SetErrorString("unable to read data");
|
|
|
|
}
|
|
|
|
if (log)
|
|
|
|
log->Printf("SBData::GetAddress (error=%p,offset=%" PRIu64 ") => "
|
|
|
|
"(%p)",
|
|
|
|
static_cast<void *>(error.get()), offset,
|
|
|
|
reinterpret_cast<void *>(value));
|
|
|
|
return value;
|
|
|
|
}
|
|
|
|
|
|
|
|
uint8_t SBData::GetUnsignedInt8(lldb::SBError &error, lldb::offset_t offset) {
|
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
|
|
|
|
uint8_t value = 0;
|
|
|
|
if (!m_opaque_sp.get()) {
|
|
|
|
error.SetErrorString("no value to read from");
|
|
|
|
} else {
|
|
|
|
uint32_t old_offset = offset;
|
|
|
|
value = m_opaque_sp->GetU8(&offset);
|
|
|
|
if (offset == old_offset)
|
|
|
|
error.SetErrorString("unable to read data");
|
|
|
|
}
|
|
|
|
if (log)
|
|
|
|
log->Printf("SBData::GetUnsignedInt8 (error=%p,offset=%" PRIu64 ") => "
|
|
|
|
"(%c)",
|
|
|
|
static_cast<void *>(error.get()), offset, value);
|
|
|
|
return value;
|
|
|
|
}
|
|
|
|
|
|
|
|
uint16_t SBData::GetUnsignedInt16(lldb::SBError &error, lldb::offset_t offset) {
|
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
|
|
|
|
uint16_t value = 0;
|
|
|
|
if (!m_opaque_sp.get()) {
|
|
|
|
error.SetErrorString("no value to read from");
|
|
|
|
} else {
|
|
|
|
uint32_t old_offset = offset;
|
|
|
|
value = m_opaque_sp->GetU16(&offset);
|
|
|
|
if (offset == old_offset)
|
|
|
|
error.SetErrorString("unable to read data");
|
|
|
|
}
|
|
|
|
if (log)
|
|
|
|
log->Printf("SBData::GetUnsignedInt16 (error=%p,offset=%" PRIu64 ") => "
|
|
|
|
"(%hd)",
|
|
|
|
static_cast<void *>(error.get()), offset, value);
|
|
|
|
return value;
|
|
|
|
}
|
|
|
|
|
|
|
|
uint32_t SBData::GetUnsignedInt32(lldb::SBError &error, lldb::offset_t offset) {
|
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
|
|
|
|
uint32_t value = 0;
|
|
|
|
if (!m_opaque_sp.get()) {
|
|
|
|
error.SetErrorString("no value to read from");
|
|
|
|
} else {
|
|
|
|
uint32_t old_offset = offset;
|
|
|
|
value = m_opaque_sp->GetU32(&offset);
|
|
|
|
if (offset == old_offset)
|
|
|
|
error.SetErrorString("unable to read data");
|
|
|
|
}
|
|
|
|
if (log)
|
|
|
|
log->Printf("SBData::GetUnsignedInt32 (error=%p,offset=%" PRIu64 ") => "
|
|
|
|
"(%d)",
|
|
|
|
static_cast<void *>(error.get()), offset, value);
|
|
|
|
return value;
|
|
|
|
}
|
|
|
|
|
|
|
|
uint64_t SBData::GetUnsignedInt64(lldb::SBError &error, lldb::offset_t offset) {
|
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
|
|
|
|
uint64_t value = 0;
|
|
|
|
if (!m_opaque_sp.get()) {
|
|
|
|
error.SetErrorString("no value to read from");
|
|
|
|
} else {
|
|
|
|
uint32_t old_offset = offset;
|
|
|
|
value = m_opaque_sp->GetU64(&offset);
|
|
|
|
if (offset == old_offset)
|
|
|
|
error.SetErrorString("unable to read data");
|
|
|
|
}
|
|
|
|
if (log)
|
|
|
|
log->Printf("SBData::GetUnsignedInt64 (error=%p,offset=%" PRIu64 ") => "
|
|
|
|
"(%" PRId64 ")",
|
|
|
|
static_cast<void *>(error.get()), offset, value);
|
|
|
|
return value;
|
|
|
|
}
|
|
|
|
|
|
|
|
int8_t SBData::GetSignedInt8(lldb::SBError &error, lldb::offset_t offset) {
|
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
|
|
|
|
int8_t value = 0;
|
|
|
|
if (!m_opaque_sp.get()) {
|
|
|
|
error.SetErrorString("no value to read from");
|
|
|
|
} else {
|
|
|
|
uint32_t old_offset = offset;
|
|
|
|
value = (int8_t)m_opaque_sp->GetMaxS64(&offset, 1);
|
|
|
|
if (offset == old_offset)
|
|
|
|
error.SetErrorString("unable to read data");
|
|
|
|
}
|
|
|
|
if (log)
|
|
|
|
log->Printf("SBData::GetSignedInt8 (error=%p,offset=%" PRIu64 ") => "
|
|
|
|
"(%c)",
|
|
|
|
static_cast<void *>(error.get()), offset, value);
|
|
|
|
return value;
|
|
|
|
}
|
|
|
|
|
|
|
|
int16_t SBData::GetSignedInt16(lldb::SBError &error, lldb::offset_t offset) {
|
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
|
|
|
|
int16_t value = 0;
|
|
|
|
if (!m_opaque_sp.get()) {
|
|
|
|
error.SetErrorString("no value to read from");
|
|
|
|
} else {
|
|
|
|
uint32_t old_offset = offset;
|
|
|
|
value = (int16_t)m_opaque_sp->GetMaxS64(&offset, 2);
|
|
|
|
if (offset == old_offset)
|
|
|
|
error.SetErrorString("unable to read data");
|
|
|
|
}
|
|
|
|
if (log)
|
|
|
|
log->Printf("SBData::GetSignedInt16 (error=%p,offset=%" PRIu64 ") => "
|
|
|
|
"(%hd)",
|
|
|
|
static_cast<void *>(error.get()), offset, value);
|
|
|
|
return value;
|
|
|
|
}
|
|
|
|
|
|
|
|
int32_t SBData::GetSignedInt32(lldb::SBError &error, lldb::offset_t offset) {
|
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
|
|
|
|
int32_t value = 0;
|
|
|
|
if (!m_opaque_sp.get()) {
|
|
|
|
error.SetErrorString("no value to read from");
|
|
|
|
} else {
|
|
|
|
uint32_t old_offset = offset;
|
|
|
|
value = (int32_t)m_opaque_sp->GetMaxS64(&offset, 4);
|
|
|
|
if (offset == old_offset)
|
|
|
|
error.SetErrorString("unable to read data");
|
|
|
|
}
|
|
|
|
if (log)
|
|
|
|
log->Printf("SBData::GetSignedInt32 (error=%p,offset=%" PRIu64 ") => "
|
|
|
|
"(%d)",
|
|
|
|
static_cast<void *>(error.get()), offset, value);
|
|
|
|
return value;
|
|
|
|
}
|
|
|
|
|
|
|
|
int64_t SBData::GetSignedInt64(lldb::SBError &error, lldb::offset_t offset) {
|
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
|
|
|
|
int64_t value = 0;
|
|
|
|
if (!m_opaque_sp.get()) {
|
|
|
|
error.SetErrorString("no value to read from");
|
|
|
|
} else {
|
|
|
|
uint32_t old_offset = offset;
|
|
|
|
value = (int64_t)m_opaque_sp->GetMaxS64(&offset, 8);
|
|
|
|
if (offset == old_offset)
|
|
|
|
error.SetErrorString("unable to read data");
|
|
|
|
}
|
|
|
|
if (log)
|
|
|
|
log->Printf("SBData::GetSignedInt64 (error=%p,offset=%" PRIu64 ") => "
|
|
|
|
"(%" PRId64 ")",
|
|
|
|
static_cast<void *>(error.get()), offset, value);
|
|
|
|
return value;
|
|
|
|
}
|
|
|
|
|
|
|
|
const char *SBData::GetString(lldb::SBError &error, lldb::offset_t offset) {
|
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
|
|
|
|
const char *value = 0;
|
|
|
|
if (!m_opaque_sp.get()) {
|
|
|
|
error.SetErrorString("no value to read from");
|
|
|
|
} else {
|
|
|
|
uint32_t old_offset = offset;
|
|
|
|
value = m_opaque_sp->GetCStr(&offset);
|
|
|
|
if (offset == old_offset || (value == NULL))
|
|
|
|
error.SetErrorString("unable to read data");
|
|
|
|
}
|
|
|
|
if (log)
|
|
|
|
log->Printf("SBData::GetString (error=%p,offset=%" PRIu64 ") => (%p)",
|
|
|
|
static_cast<void *>(error.get()), offset,
|
|
|
|
static_cast<const void *>(value));
|
|
|
|
return value;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool SBData::GetDescription(lldb::SBStream &description,
|
|
|
|
lldb::addr_t base_addr) {
|
|
|
|
Stream &strm = description.ref();
|
|
|
|
|
|
|
|
if (m_opaque_sp) {
|
2017-03-04 04:57:05 +08:00
|
|
|
DumpDataExtractor(*m_opaque_sp, &strm, 0, lldb::eFormatBytesWithASCII, 1,
|
2016-09-07 04:57:50 +08:00
|
|
|
m_opaque_sp->GetByteSize(), 16, base_addr, 0, 0);
|
|
|
|
} else
|
|
|
|
strm.PutCString("No value");
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
size_t SBData::ReadRawData(lldb::SBError &error, lldb::offset_t offset,
|
|
|
|
void *buf, size_t size) {
|
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
|
|
|
|
void *ok = NULL;
|
|
|
|
if (!m_opaque_sp.get()) {
|
|
|
|
error.SetErrorString("no value to read from");
|
|
|
|
} else {
|
|
|
|
uint32_t old_offset = offset;
|
|
|
|
ok = m_opaque_sp->GetU8(&offset, buf, size);
|
|
|
|
if ((offset == old_offset) || (ok == NULL))
|
|
|
|
error.SetErrorString("unable to read data");
|
|
|
|
}
|
|
|
|
if (log)
|
|
|
|
log->Printf("SBData::ReadRawData (error=%p,offset=%" PRIu64
|
|
|
|
",buf=%p,size=%" PRIu64 ") => "
|
|
|
|
"(%p)",
|
|
|
|
static_cast<void *>(error.get()), offset,
|
|
|
|
static_cast<void *>(buf), static_cast<uint64_t>(size),
|
|
|
|
static_cast<void *>(ok));
|
|
|
|
return ok ? size : 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
void SBData::SetData(lldb::SBError &error, const void *buf, size_t size,
|
|
|
|
lldb::ByteOrder endian, uint8_t addr_size) {
|
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
|
|
|
|
if (!m_opaque_sp.get())
|
|
|
|
m_opaque_sp.reset(new DataExtractor(buf, size, endian, addr_size));
|
|
|
|
else
|
2017-01-26 05:50:28 +08:00
|
|
|
{
|
2016-09-07 04:57:50 +08:00
|
|
|
m_opaque_sp->SetData(buf, size, endian);
|
2017-01-26 05:50:28 +08:00
|
|
|
m_opaque_sp->SetAddressByteSize(addr_size);
|
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (log)
|
|
|
|
log->Printf("SBData::SetData (error=%p,buf=%p,size=%" PRIu64
|
|
|
|
",endian=%d,addr_size=%c) => "
|
|
|
|
"(%p)",
|
|
|
|
static_cast<void *>(error.get()),
|
|
|
|
static_cast<const void *>(buf), static_cast<uint64_t>(size),
|
|
|
|
endian, addr_size, static_cast<void *>(m_opaque_sp.get()));
|
|
|
|
}
|
|
|
|
|
|
|
|
bool SBData::Append(const SBData &rhs) {
|
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
|
|
|
|
bool value = false;
|
|
|
|
if (m_opaque_sp.get() && rhs.m_opaque_sp.get())
|
|
|
|
value = m_opaque_sp.get()->Append(*rhs.m_opaque_sp);
|
|
|
|
if (log)
|
|
|
|
log->Printf("SBData::Append (rhs=%p) => (%s)",
|
|
|
|
static_cast<void *>(rhs.get()), value ? "true" : "false");
|
|
|
|
return value;
|
|
|
|
}
|
|
|
|
|
|
|
|
lldb::SBData SBData::CreateDataFromCString(lldb::ByteOrder endian,
|
|
|
|
uint32_t addr_byte_size,
|
|
|
|
const char *data) {
|
|
|
|
if (!data || !data[0])
|
|
|
|
return SBData();
|
|
|
|
|
|
|
|
uint32_t data_len = strlen(data);
|
|
|
|
|
|
|
|
lldb::DataBufferSP buffer_sp(new DataBufferHeap(data, data_len));
|
|
|
|
lldb::DataExtractorSP data_sp(
|
|
|
|
new DataExtractor(buffer_sp, endian, 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
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
SBData ret(data_sp);
|
|
|
|
|
|
|
|
return ret;
|
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
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
lldb::SBData SBData::CreateDataFromUInt64Array(lldb::ByteOrder endian,
|
|
|
|
uint32_t addr_byte_size,
|
|
|
|
uint64_t *array,
|
|
|
|
size_t array_len) {
|
|
|
|
if (!array || array_len == 0)
|
|
|
|
return SBData();
|
|
|
|
|
|
|
|
size_t data_len = array_len * sizeof(uint64_t);
|
|
|
|
|
|
|
|
lldb::DataBufferSP buffer_sp(new DataBufferHeap(array, data_len));
|
|
|
|
lldb::DataExtractorSP data_sp(
|
|
|
|
new DataExtractor(buffer_sp, endian, addr_byte_size));
|
|
|
|
|
|
|
|
SBData ret(data_sp);
|
|
|
|
|
|
|
|
return ret;
|
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
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
lldb::SBData SBData::CreateDataFromUInt32Array(lldb::ByteOrder endian,
|
|
|
|
uint32_t addr_byte_size,
|
|
|
|
uint32_t *array,
|
|
|
|
size_t array_len) {
|
|
|
|
if (!array || array_len == 0)
|
|
|
|
return SBData();
|
|
|
|
|
|
|
|
size_t data_len = array_len * sizeof(uint32_t);
|
|
|
|
|
|
|
|
lldb::DataBufferSP buffer_sp(new DataBufferHeap(array, data_len));
|
|
|
|
lldb::DataExtractorSP data_sp(
|
|
|
|
new DataExtractor(buffer_sp, endian, addr_byte_size));
|
|
|
|
|
|
|
|
SBData ret(data_sp);
|
|
|
|
|
|
|
|
return ret;
|
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
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
lldb::SBData SBData::CreateDataFromSInt64Array(lldb::ByteOrder endian,
|
|
|
|
uint32_t addr_byte_size,
|
|
|
|
int64_t *array,
|
|
|
|
size_t array_len) {
|
|
|
|
if (!array || array_len == 0)
|
|
|
|
return SBData();
|
|
|
|
|
|
|
|
size_t data_len = array_len * sizeof(int64_t);
|
|
|
|
|
|
|
|
lldb::DataBufferSP buffer_sp(new DataBufferHeap(array, data_len));
|
|
|
|
lldb::DataExtractorSP data_sp(
|
|
|
|
new DataExtractor(buffer_sp, endian, addr_byte_size));
|
|
|
|
|
|
|
|
SBData ret(data_sp);
|
|
|
|
|
|
|
|
return ret;
|
2012-01-07 08:45:50 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
lldb::SBData SBData::CreateDataFromSInt32Array(lldb::ByteOrder endian,
|
|
|
|
uint32_t addr_byte_size,
|
|
|
|
int32_t *array,
|
|
|
|
size_t array_len) {
|
|
|
|
if (!array || array_len == 0)
|
|
|
|
return SBData();
|
|
|
|
|
|
|
|
size_t data_len = array_len * sizeof(int32_t);
|
|
|
|
|
|
|
|
lldb::DataBufferSP buffer_sp(new DataBufferHeap(array, data_len));
|
|
|
|
lldb::DataExtractorSP data_sp(
|
|
|
|
new DataExtractor(buffer_sp, endian, addr_byte_size));
|
|
|
|
|
|
|
|
SBData ret(data_sp);
|
|
|
|
|
|
|
|
return ret;
|
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
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
lldb::SBData SBData::CreateDataFromDoubleArray(lldb::ByteOrder endian,
|
|
|
|
uint32_t addr_byte_size,
|
|
|
|
double *array,
|
|
|
|
size_t array_len) {
|
|
|
|
if (!array || array_len == 0)
|
|
|
|
return SBData();
|
|
|
|
|
|
|
|
size_t data_len = array_len * sizeof(double);
|
|
|
|
|
|
|
|
lldb::DataBufferSP buffer_sp(new DataBufferHeap(array, data_len));
|
|
|
|
lldb::DataExtractorSP data_sp(
|
|
|
|
new DataExtractor(buffer_sp, endian, addr_byte_size));
|
|
|
|
|
|
|
|
SBData ret(data_sp);
|
|
|
|
|
|
|
|
return ret;
|
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
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
bool SBData::SetDataFromCString(const char *data) {
|
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (!data) {
|
2012-01-07 08:45:50 +08:00
|
|
|
if (log)
|
2016-09-07 04:57:50 +08:00
|
|
|
log->Printf("SBData::SetDataFromCString (data=%p) => false",
|
|
|
|
static_cast<const void *>(data));
|
|
|
|
return false;
|
|
|
|
}
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
size_t data_len = strlen(data);
|
2012-01-07 08:45:50 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
lldb::DataBufferSP buffer_sp(new DataBufferHeap(data, data_len));
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (!m_opaque_sp.get())
|
|
|
|
m_opaque_sp.reset(
|
|
|
|
new DataExtractor(buffer_sp, GetByteOrder(), GetAddressByteSize()));
|
|
|
|
else
|
|
|
|
m_opaque_sp->SetData(buffer_sp);
|
2012-01-07 08:45:50 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (log)
|
|
|
|
log->Printf("SBData::SetDataFromCString (data=%p) => true",
|
|
|
|
static_cast<const void *>(data));
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
return true;
|
|
|
|
}
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
bool SBData::SetDataFromUInt64Array(uint64_t *array, size_t array_len) {
|
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (!array || array_len == 0) {
|
2012-01-07 08:45:50 +08:00
|
|
|
if (log)
|
2016-09-07 04:57:50 +08:00
|
|
|
log->Printf(
|
|
|
|
"SBData::SetDataFromUInt64Array (array=%p, array_len = %" PRIu64
|
|
|
|
") => "
|
|
|
|
"false",
|
|
|
|
static_cast<void *>(array), static_cast<uint64_t>(array_len));
|
|
|
|
return false;
|
|
|
|
}
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
size_t data_len = array_len * sizeof(uint64_t);
|
2012-01-07 08:45:50 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
lldb::DataBufferSP buffer_sp(new DataBufferHeap(array, data_len));
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (!m_opaque_sp.get())
|
|
|
|
m_opaque_sp.reset(
|
|
|
|
new DataExtractor(buffer_sp, GetByteOrder(), GetAddressByteSize()));
|
|
|
|
else
|
|
|
|
m_opaque_sp->SetData(buffer_sp);
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (log)
|
|
|
|
log->Printf("SBData::SetDataFromUInt64Array (array=%p, array_len = %" PRIu64
|
|
|
|
") => "
|
|
|
|
"true",
|
|
|
|
static_cast<void *>(array), static_cast<uint64_t>(array_len));
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
return true;
|
|
|
|
}
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
bool SBData::SetDataFromUInt32Array(uint32_t *array, size_t array_len) {
|
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (!array || array_len == 0) {
|
2012-01-07 08:45:50 +08:00
|
|
|
if (log)
|
2016-09-07 04:57:50 +08:00
|
|
|
log->Printf(
|
|
|
|
"SBData::SetDataFromUInt32Array (array=%p, array_len = %" PRIu64
|
|
|
|
") => "
|
|
|
|
"false",
|
|
|
|
static_cast<void *>(array), static_cast<uint64_t>(array_len));
|
|
|
|
return false;
|
|
|
|
}
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
size_t data_len = array_len * sizeof(uint32_t);
|
2012-01-07 08:45:50 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
lldb::DataBufferSP buffer_sp(new DataBufferHeap(array, data_len));
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (!m_opaque_sp.get())
|
|
|
|
m_opaque_sp.reset(
|
|
|
|
new DataExtractor(buffer_sp, GetByteOrder(), GetAddressByteSize()));
|
|
|
|
else
|
|
|
|
m_opaque_sp->SetData(buffer_sp);
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (log)
|
|
|
|
log->Printf("SBData::SetDataFromUInt32Array (array=%p, array_len = %" PRIu64
|
|
|
|
") => "
|
|
|
|
"true",
|
|
|
|
static_cast<void *>(array), static_cast<uint64_t>(array_len));
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
return true;
|
|
|
|
}
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
bool SBData::SetDataFromSInt64Array(int64_t *array, size_t array_len) {
|
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (!array || array_len == 0) {
|
2012-01-07 08:45:50 +08:00
|
|
|
if (log)
|
2016-09-07 04:57:50 +08:00
|
|
|
log->Printf(
|
|
|
|
"SBData::SetDataFromSInt64Array (array=%p, array_len = %" PRIu64
|
|
|
|
") => "
|
|
|
|
"false",
|
|
|
|
static_cast<void *>(array), static_cast<uint64_t>(array_len));
|
|
|
|
return false;
|
|
|
|
}
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
size_t data_len = array_len * sizeof(int64_t);
|
2012-01-07 08:45:50 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
lldb::DataBufferSP buffer_sp(new DataBufferHeap(array, data_len));
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (!m_opaque_sp.get())
|
|
|
|
m_opaque_sp.reset(
|
|
|
|
new DataExtractor(buffer_sp, GetByteOrder(), GetAddressByteSize()));
|
|
|
|
else
|
|
|
|
m_opaque_sp->SetData(buffer_sp);
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (log)
|
|
|
|
log->Printf("SBData::SetDataFromSInt64Array (array=%p, array_len = %" PRIu64
|
|
|
|
") => "
|
|
|
|
"true",
|
|
|
|
static_cast<void *>(array), static_cast<uint64_t>(array_len));
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
return true;
|
|
|
|
}
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
bool SBData::SetDataFromSInt32Array(int32_t *array, size_t array_len) {
|
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (!array || array_len == 0) {
|
2012-01-07 08:45:50 +08:00
|
|
|
if (log)
|
2016-09-07 04:57:50 +08:00
|
|
|
log->Printf(
|
|
|
|
"SBData::SetDataFromSInt32Array (array=%p, array_len = %" PRIu64
|
|
|
|
") => "
|
|
|
|
"false",
|
|
|
|
static_cast<void *>(array), static_cast<uint64_t>(array_len));
|
|
|
|
return false;
|
|
|
|
}
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
size_t data_len = array_len * sizeof(int32_t);
|
2012-01-07 08:45:50 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
lldb::DataBufferSP buffer_sp(new DataBufferHeap(array, data_len));
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (!m_opaque_sp.get())
|
|
|
|
m_opaque_sp.reset(
|
|
|
|
new DataExtractor(buffer_sp, GetByteOrder(), GetAddressByteSize()));
|
|
|
|
else
|
|
|
|
m_opaque_sp->SetData(buffer_sp);
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (log)
|
|
|
|
log->Printf("SBData::SetDataFromSInt32Array (array=%p, array_len = %" PRIu64
|
|
|
|
") => "
|
|
|
|
"true",
|
|
|
|
static_cast<void *>(array), static_cast<uint64_t>(array_len));
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
return true;
|
|
|
|
}
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
bool SBData::SetDataFromDoubleArray(double *array, size_t array_len) {
|
|
|
|
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
|
2014-04-04 12:06:10 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (!array || array_len == 0) {
|
2012-01-07 08:45:50 +08:00
|
|
|
if (log)
|
2016-09-07 04:57:50 +08:00
|
|
|
log->Printf(
|
|
|
|
"SBData::SetDataFromDoubleArray (array=%p, array_len = %" PRIu64
|
|
|
|
") => "
|
|
|
|
"false",
|
|
|
|
static_cast<void *>(array), static_cast<uint64_t>(array_len));
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
size_t data_len = array_len * sizeof(double);
|
|
|
|
|
|
|
|
lldb::DataBufferSP buffer_sp(new DataBufferHeap(array, data_len));
|
|
|
|
|
|
|
|
if (!m_opaque_sp.get())
|
|
|
|
m_opaque_sp.reset(
|
|
|
|
new DataExtractor(buffer_sp, GetByteOrder(), GetAddressByteSize()));
|
|
|
|
else
|
|
|
|
m_opaque_sp->SetData(buffer_sp);
|
|
|
|
|
|
|
|
if (log)
|
|
|
|
log->Printf("SBData::SetDataFromDoubleArray (array=%p, array_len = %" PRIu64
|
|
|
|
") => "
|
|
|
|
"true",
|
|
|
|
static_cast<void *>(array), static_cast<uint64_t>(array_len));
|
|
|
|
|
|
|
|
return true;
|
2012-01-07 08:45:50 +08:00
|
|
|
}
|