2010-06-08 16:52:24 +00:00
|
|
|
//===-- DataExtractor.cpp ---------------------------------------*- C++ -*-===//
|
|
|
|
|
//
|
2019-01-19 08:50:56 +00:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2010-06-08 16:52:24 +00:00
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
2017-04-06 18:12:24 +00:00
|
|
|
#include "lldb/Utility/DataExtractor.h"
|
|
|
|
|
|
2018-11-11 23:16:43 +00:00
|
|
|
#include "lldb/lldb-defines.h"
|
|
|
|
|
#include "lldb/lldb-enumerations.h"
|
|
|
|
|
#include "lldb/lldb-forward.h"
|
|
|
|
|
#include "lldb/lldb-types.h"
|
2013-06-11 21:56:55 +00:00
|
|
|
|
2017-03-04 01:30:05 +00:00
|
|
|
#include "lldb/Utility/DataBuffer.h"
|
|
|
|
|
#include "lldb/Utility/DataBufferHeap.h"
|
2017-02-14 19:06:07 +00:00
|
|
|
#include "lldb/Utility/Endian.h"
|
2017-10-11 08:48:18 +00:00
|
|
|
#include "lldb/Utility/LLDBAssert.h"
|
2017-03-03 20:56:28 +00:00
|
|
|
#include "lldb/Utility/Log.h"
|
2017-02-02 21:39:50 +00:00
|
|
|
#include "lldb/Utility/Stream.h"
|
|
|
|
|
#include "lldb/Utility/StreamString.h"
|
2017-03-04 01:30:05 +00:00
|
|
|
#include "lldb/Utility/UUID.h"
|
|
|
|
|
|
|
|
|
|
#include "llvm/ADT/ArrayRef.h"
|
|
|
|
|
#include "llvm/ADT/SmallVector.h"
|
|
|
|
|
#include "llvm/Support/MD5.h"
|
|
|
|
|
#include "llvm/Support/MathExtras.h"
|
2010-06-08 16:52:24 +00:00
|
|
|
|
2018-11-11 23:16:43 +00:00
|
|
|
#include <algorithm>
|
|
|
|
|
#include <array>
|
2017-04-06 18:12:24 +00:00
|
|
|
#include <cassert>
|
2018-11-11 23:16:43 +00:00
|
|
|
#include <cstdint>
|
2017-04-06 18:12:24 +00:00
|
|
|
#include <string>
|
|
|
|
|
|
2018-11-11 23:16:43 +00:00
|
|
|
#include <ctype.h>
|
|
|
|
|
#include <inttypes.h>
|
|
|
|
|
#include <string.h>
|
2017-04-06 18:12:24 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
using namespace lldb;
|
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
|
2013-01-25 18:06:21 +00:00
|
|
|
static inline uint16_t ReadInt16(const unsigned char *ptr, offset_t offset) {
|
2014-01-25 05:12:35 +00:00
|
|
|
uint16_t value;
|
|
|
|
|
memcpy(&value, ptr + offset, 2);
|
|
|
|
|
return value;
|
2010-06-10 23:56:16 +00:00
|
|
|
}
|
2014-01-25 05:12:35 +00:00
|
|
|
|
2014-03-20 06:08:36 +00:00
|
|
|
static inline uint32_t ReadInt32(const unsigned char *ptr,
|
|
|
|
|
offset_t offset = 0) {
|
2014-01-25 05:12:35 +00:00
|
|
|
uint32_t value;
|
|
|
|
|
memcpy(&value, ptr + offset, 4);
|
|
|
|
|
return value;
|
2010-06-10 23:56:16 +00:00
|
|
|
}
|
2010-06-12 01:03:17 +00:00
|
|
|
|
2014-03-20 06:08:36 +00:00
|
|
|
static inline uint64_t ReadInt64(const unsigned char *ptr,
|
|
|
|
|
offset_t offset = 0) {
|
2014-01-25 05:12:35 +00:00
|
|
|
uint64_t value;
|
|
|
|
|
memcpy(&value, ptr + offset, 8);
|
|
|
|
|
return value;
|
2010-06-10 23:56:16 +00:00
|
|
|
}
|
2010-06-12 01:03:17 +00:00
|
|
|
|
2013-02-08 22:02:02 +00:00
|
|
|
static inline uint16_t ReadInt16(const void *ptr) {
|
2014-01-25 05:12:35 +00:00
|
|
|
uint16_t value;
|
|
|
|
|
memcpy(&value, ptr, 2);
|
|
|
|
|
return value;
|
2013-02-08 22:02:02 +00:00
|
|
|
}
|
2014-01-25 05:12:35 +00:00
|
|
|
|
2013-01-25 18:06:21 +00:00
|
|
|
static inline uint16_t ReadSwapInt16(const unsigned char *ptr,
|
|
|
|
|
offset_t offset) {
|
2014-01-25 05:12:35 +00:00
|
|
|
uint16_t value;
|
|
|
|
|
memcpy(&value, ptr + offset, 2);
|
|
|
|
|
return llvm::ByteSwap_16(value);
|
2010-06-10 23:56:16 +00:00
|
|
|
}
|
2010-06-12 01:03:17 +00:00
|
|
|
|
2013-01-25 18:06:21 +00:00
|
|
|
static inline uint32_t ReadSwapInt32(const unsigned char *ptr,
|
|
|
|
|
offset_t offset) {
|
2014-01-25 05:12:35 +00:00
|
|
|
uint32_t value;
|
|
|
|
|
memcpy(&value, ptr + offset, 4);
|
|
|
|
|
return llvm::ByteSwap_32(value);
|
2010-06-10 23:56:16 +00:00
|
|
|
}
|
2014-01-25 05:12:35 +00:00
|
|
|
|
2013-01-25 18:06:21 +00:00
|
|
|
static inline uint64_t ReadSwapInt64(const unsigned char *ptr,
|
|
|
|
|
offset_t offset) {
|
2014-01-25 05:12:35 +00:00
|
|
|
uint64_t value;
|
|
|
|
|
memcpy(&value, ptr + offset, 8);
|
|
|
|
|
return llvm::ByteSwap_64(value);
|
2010-06-10 23:56:16 +00:00
|
|
|
}
|
|
|
|
|
|
2013-02-08 22:02:02 +00:00
|
|
|
static inline uint16_t ReadSwapInt16(const void *ptr) {
|
2014-01-25 05:12:35 +00:00
|
|
|
uint16_t value;
|
|
|
|
|
memcpy(&value, ptr, 2);
|
|
|
|
|
return llvm::ByteSwap_16(value);
|
2013-02-08 22:02:02 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline uint32_t ReadSwapInt32(const void *ptr) {
|
2014-01-25 05:12:35 +00:00
|
|
|
uint32_t value;
|
|
|
|
|
memcpy(&value, ptr, 4);
|
|
|
|
|
return llvm::ByteSwap_32(value);
|
2013-02-08 22:02:02 +00:00
|
|
|
}
|
2014-01-25 05:12:35 +00:00
|
|
|
|
2013-02-08 22:02:02 +00:00
|
|
|
static inline uint64_t ReadSwapInt64(const void *ptr) {
|
2014-01-25 05:12:35 +00:00
|
|
|
uint64_t value;
|
|
|
|
|
memcpy(&value, ptr, 8);
|
|
|
|
|
return llvm::ByteSwap_64(value);
|
2013-02-08 22:02:02 +00:00
|
|
|
}
|
|
|
|
|
|
2017-10-11 08:48:18 +00:00
|
|
|
static inline uint64_t ReadMaxInt64(const uint8_t *data, size_t byte_size,
|
|
|
|
|
ByteOrder byte_order) {
|
|
|
|
|
uint64_t res = 0;
|
|
|
|
|
if (byte_order == eByteOrderBig)
|
|
|
|
|
for (size_t i = 0; i < byte_size; ++i)
|
|
|
|
|
res = (res << 8) | data[i];
|
|
|
|
|
else {
|
|
|
|
|
assert(byte_order == eByteOrderLittle);
|
|
|
|
|
for (size_t i = 0; i < byte_size; ++i)
|
|
|
|
|
res = (res << 8) | data[byte_size - 1 - i];
|
|
|
|
|
}
|
|
|
|
|
return res;
|
|
|
|
|
}
|
|
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
DataExtractor::DataExtractor()
|
2016-03-02 02:18:18 +00:00
|
|
|
: m_start(nullptr), m_end(nullptr),
|
2015-11-07 04:40:13 +00:00
|
|
|
m_byte_order(endian::InlHostByteOrder()), m_addr_size(sizeof(void *)),
|
2014-09-29 08:02:24 +00:00
|
|
|
m_data_sp(), m_target_byte_size(1) {}
|
2010-06-08 16:52:24 +00:00
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// This constructor allows us to use data that is owned by someone else. The
|
|
|
|
|
// data must stay around as long as this object is valid.
|
2014-09-29 08:02:24 +00:00
|
|
|
DataExtractor::DataExtractor(const void *data, offset_t length,
|
|
|
|
|
ByteOrder endian, uint32_t addr_size,
|
|
|
|
|
uint32_t target_byte_size /*=1*/)
|
2015-10-18 19:34:38 +00:00
|
|
|
: m_start(const_cast<uint8_t *>(reinterpret_cast<const uint8_t *>(data))),
|
|
|
|
|
m_end(const_cast<uint8_t *>(reinterpret_cast<const uint8_t *>(data)) +
|
|
|
|
|
length),
|
2010-06-08 16:52:24 +00:00
|
|
|
m_byte_order(endian), m_addr_size(addr_size), m_data_sp(),
|
2014-09-29 08:02:24 +00:00
|
|
|
m_target_byte_size(target_byte_size) {
|
2015-11-05 23:41:08 +00:00
|
|
|
assert(addr_size == 4 || addr_size == 8);
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// Make a shared pointer reference to the shared data in "data_sp" and set the
|
|
|
|
|
// endian swapping setting to "swap", and the address size to "addr_size". The
|
|
|
|
|
// shared data reference will ensure the data lives as long as any
|
|
|
|
|
// DataExtractor objects exist that have a reference to this data.
|
2014-09-29 08:02:24 +00:00
|
|
|
DataExtractor::DataExtractor(const DataBufferSP &data_sp, ByteOrder endian,
|
|
|
|
|
uint32_t addr_size,
|
|
|
|
|
uint32_t target_byte_size /*=1*/)
|
2010-06-08 16:52:24 +00:00
|
|
|
: m_start(nullptr), m_end(nullptr), m_byte_order(endian),
|
2016-03-02 02:18:18 +00:00
|
|
|
m_addr_size(addr_size), m_data_sp(),
|
2014-09-29 08:02:24 +00:00
|
|
|
m_target_byte_size(target_byte_size) {
|
2015-11-05 23:41:08 +00:00
|
|
|
assert(addr_size == 4 || addr_size == 8);
|
2010-06-08 16:52:24 +00:00
|
|
|
SetData(data_sp);
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// Initialize this object with a subset of the data bytes in "data". If "data"
|
|
|
|
|
// contains shared data, then a reference to this shared data will added and
|
|
|
|
|
// the shared data will stay around as long as any object contains a reference
|
|
|
|
|
// to that data. The endian swap and address size settings are copied from
|
|
|
|
|
// "data".
|
2014-09-29 08:02:24 +00:00
|
|
|
DataExtractor::DataExtractor(const DataExtractor &data, offset_t offset,
|
|
|
|
|
offset_t length, uint32_t target_byte_size /*=1*/)
|
2010-06-08 16:52:24 +00:00
|
|
|
: m_start(nullptr), m_end(nullptr), m_byte_order(data.m_byte_order),
|
|
|
|
|
m_addr_size(data.m_addr_size), m_data_sp(),
|
2014-09-29 08:02:24 +00:00
|
|
|
m_target_byte_size(target_byte_size) {
|
2015-11-05 23:41:08 +00:00
|
|
|
assert(m_addr_size == 4 || m_addr_size == 8);
|
2010-06-08 16:52:24 +00:00
|
|
|
if (data.ValidOffset(offset)) {
|
2013-01-25 18:06:21 +00:00
|
|
|
offset_t bytes_available = data.GetByteSize() - offset;
|
2010-06-08 16:52:24 +00:00
|
|
|
if (length > bytes_available)
|
|
|
|
|
length = bytes_available;
|
|
|
|
|
SetData(data, offset, length);
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2011-05-30 00:49:24 +00:00
|
|
|
DataExtractor::DataExtractor(const DataExtractor &rhs)
|
|
|
|
|
: m_start(rhs.m_start), m_end(rhs.m_end), m_byte_order(rhs.m_byte_order),
|
|
|
|
|
m_addr_size(rhs.m_addr_size), m_data_sp(rhs.m_data_sp),
|
2014-09-29 08:02:24 +00:00
|
|
|
m_target_byte_size(rhs.m_target_byte_size) {
|
2015-11-05 23:41:08 +00:00
|
|
|
assert(m_addr_size == 4 || m_addr_size == 8);
|
2011-05-30 00:49:24 +00:00
|
|
|
}
|
|
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
// Assignment operator
|
|
|
|
|
const DataExtractor &DataExtractor::operator=(const DataExtractor &rhs) {
|
|
|
|
|
if (this != &rhs) {
|
2011-05-30 00:49:24 +00:00
|
|
|
m_start = rhs.m_start;
|
|
|
|
|
m_end = rhs.m_end;
|
|
|
|
|
m_byte_order = rhs.m_byte_order;
|
2010-06-08 16:52:24 +00:00
|
|
|
m_addr_size = rhs.m_addr_size;
|
2011-05-30 00:49:24 +00:00
|
|
|
m_data_sp = rhs.m_data_sp;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
return *this;
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-02 02:18:18 +00:00
|
|
|
DataExtractor::~DataExtractor() = default;
|
2010-06-08 16:52:24 +00:00
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// Clears the object contents back to a default invalid state, and release any
|
|
|
|
|
// references to shared data that this object may contain.
|
2010-06-08 16:52:24 +00:00
|
|
|
void DataExtractor::Clear() {
|
2016-03-02 02:18:18 +00:00
|
|
|
m_start = nullptr;
|
|
|
|
|
m_end = nullptr;
|
2015-11-07 04:40:13 +00:00
|
|
|
m_byte_order = endian::InlHostByteOrder();
|
2015-11-05 23:41:08 +00:00
|
|
|
m_addr_size = sizeof(void *);
|
2010-06-08 16:52:24 +00:00
|
|
|
m_data_sp.reset();
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// If this object contains shared data, this function returns the offset into
|
|
|
|
|
// that shared data. Else zero is returned.
|
2010-06-08 16:52:24 +00:00
|
|
|
size_t DataExtractor::GetSharedDataOffset() const {
|
2016-03-02 02:18:18 +00:00
|
|
|
if (m_start != nullptr) {
|
2010-06-08 16:52:24 +00:00
|
|
|
const DataBuffer *data = m_data_sp.get();
|
2016-03-02 02:18:18 +00:00
|
|
|
if (data != nullptr) {
|
2010-06-08 16:52:24 +00:00
|
|
|
const uint8_t *data_bytes = data->GetBytes();
|
2016-03-02 02:18:18 +00:00
|
|
|
if (data_bytes != nullptr) {
|
2010-06-08 16:52:24 +00:00
|
|
|
assert(m_start >= data_bytes);
|
|
|
|
|
return m_start - data_bytes;
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// Set the data with which this object will extract from to data starting at
|
|
|
|
|
// BYTES and set the length of the data to LENGTH bytes long. The data is
|
|
|
|
|
// externally owned must be around at least as long as this object points to
|
|
|
|
|
// the data. No copy of the data is made, this object just refers to this data
|
|
|
|
|
// and can extract from it. If this object refers to any shared data upon
|
|
|
|
|
// entry, the reference to that data will be released. Is SWAP is set to true,
|
2010-06-08 16:52:24 +00:00
|
|
|
// any data extracted will be endian swapped.
|
2013-01-25 18:06:21 +00:00
|
|
|
lldb::offset_t DataExtractor::SetData(const void *bytes, offset_t length,
|
|
|
|
|
ByteOrder endian) {
|
2010-06-08 16:52:24 +00:00
|
|
|
m_byte_order = endian;
|
|
|
|
|
m_data_sp.reset();
|
2016-03-02 02:18:18 +00:00
|
|
|
if (bytes == nullptr || length == 0) {
|
|
|
|
|
m_start = nullptr;
|
|
|
|
|
m_end = nullptr;
|
2010-06-08 16:52:24 +00:00
|
|
|
} else {
|
2015-10-18 19:34:38 +00:00
|
|
|
m_start = const_cast<uint8_t *>(reinterpret_cast<const uint8_t *>(bytes));
|
2010-06-08 16:52:24 +00:00
|
|
|
m_end = m_start + length;
|
|
|
|
|
}
|
|
|
|
|
return GetByteSize();
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// Assign the data for this object to be a subrange in "data" starting
|
|
|
|
|
// "data_offset" bytes into "data" and ending "data_length" bytes later. If
|
|
|
|
|
// "data_offset" is not a valid offset into "data", then this object will
|
|
|
|
|
// contain no bytes. If "data_offset" is within "data" yet "data_length" is too
|
|
|
|
|
// large, the length will be capped at the number of bytes remaining in "data".
|
|
|
|
|
// If "data" contains a shared pointer to other data, then a ref counted
|
|
|
|
|
// pointer to that data will be made in this object. If "data" doesn't contain
|
|
|
|
|
// a shared pointer to data, then the bytes referred to in "data" will need to
|
|
|
|
|
// exist at least as long as this object refers to those bytes. The address
|
|
|
|
|
// size and endian swap settings are copied from the current values in "data".
|
2013-01-25 18:06:21 +00:00
|
|
|
lldb::offset_t DataExtractor::SetData(const DataExtractor &data,
|
|
|
|
|
offset_t data_offset,
|
|
|
|
|
offset_t data_length) {
|
2010-06-08 16:52:24 +00:00
|
|
|
m_addr_size = data.m_addr_size;
|
2015-11-05 23:41:08 +00:00
|
|
|
assert(m_addr_size == 4 || m_addr_size == 8);
|
2010-06-08 16:52:24 +00:00
|
|
|
// If "data" contains shared pointer to data, then we can use that
|
2016-03-02 02:18:18 +00:00
|
|
|
if (data.m_data_sp) {
|
2010-06-08 16:52:24 +00:00
|
|
|
m_byte_order = data.m_byte_order;
|
|
|
|
|
return SetData(data.m_data_sp, data.GetSharedDataOffset() + data_offset,
|
|
|
|
|
data_length);
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
// We have a DataExtractor object that just has a pointer to bytes
|
|
|
|
|
if (data.ValidOffset(data_offset)) {
|
|
|
|
|
if (data_length > data.GetByteSize() - data_offset)
|
|
|
|
|
data_length = data.GetByteSize() - data_offset;
|
|
|
|
|
return SetData(data.GetDataStart() + data_offset, data_length,
|
|
|
|
|
data.GetByteOrder());
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// Assign the data for this object to be a subrange of the shared data in
|
|
|
|
|
// "data_sp" starting "data_offset" bytes into "data_sp" and ending
|
|
|
|
|
// "data_length" bytes later. If "data_offset" is not a valid offset into
|
|
|
|
|
// "data_sp", then this object will contain no bytes. If "data_offset" is
|
|
|
|
|
// within "data_sp" yet "data_length" is too large, the length will be capped
|
|
|
|
|
// at the number of bytes remaining in "data_sp". A ref counted pointer to the
|
|
|
|
|
// data in "data_sp" will be made in this object IF the number of bytes this
|
|
|
|
|
// object refers to in greater than zero (if at least one byte was available
|
|
|
|
|
// starting at "data_offset") to ensure the data stays around as long as it is
|
|
|
|
|
// needed. The address size and endian swap settings will remain unchanged from
|
|
|
|
|
// their current settings.
|
2013-01-25 18:06:21 +00:00
|
|
|
lldb::offset_t DataExtractor::SetData(const DataBufferSP &data_sp,
|
|
|
|
|
offset_t data_offset,
|
|
|
|
|
offset_t data_length) {
|
2016-03-02 02:18:18 +00:00
|
|
|
m_start = m_end = nullptr;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
if (data_length > 0) {
|
|
|
|
|
m_data_sp = data_sp;
|
2016-03-02 02:18:18 +00:00
|
|
|
if (data_sp) {
|
2010-06-08 16:52:24 +00:00
|
|
|
const size_t data_size = data_sp->GetByteSize();
|
|
|
|
|
if (data_offset < data_size) {
|
|
|
|
|
m_start = data_sp->GetBytes() + data_offset;
|
|
|
|
|
const size_t bytes_left = data_size - data_offset;
|
|
|
|
|
// Cap the length of we asked for too many
|
|
|
|
|
if (data_length <= bytes_left)
|
|
|
|
|
m_end = m_start + data_length; // We got all the bytes we wanted
|
|
|
|
|
else
|
|
|
|
|
m_end = m_start + bytes_left; // Not all the bytes requested were
|
|
|
|
|
// available in the shared data
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
|
2013-01-25 18:06:21 +00:00
|
|
|
size_t new_size = GetByteSize();
|
2010-06-08 16:52:24 +00:00
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// Don't hold a shared pointer to the data buffer if we don't share any valid
|
|
|
|
|
// bytes in the shared buffer.
|
2010-06-08 16:52:24 +00:00
|
|
|
if (new_size == 0)
|
|
|
|
|
m_data_sp.reset();
|
|
|
|
|
|
|
|
|
|
return new_size;
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// Extract a single unsigned char from the binary data and update the offset
|
|
|
|
|
// pointed to by "offset_ptr".
|
2010-06-08 16:52:24 +00:00
|
|
|
//
|
|
|
|
|
// RETURNS the byte that was extracted, or zero on failure.
|
2013-01-25 18:06:21 +00:00
|
|
|
uint8_t DataExtractor::GetU8(offset_t *offset_ptr) const {
|
2019-05-23 05:12:11 +00:00
|
|
|
const uint8_t *data = static_cast<const uint8_t *>(GetData(offset_ptr, 1));
|
2013-02-08 22:02:02 +00:00
|
|
|
if (data)
|
|
|
|
|
return *data;
|
|
|
|
|
return 0;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// Extract "count" unsigned chars from the binary data and update the offset
|
|
|
|
|
// pointed to by "offset_ptr". The extracted data is copied into "dst".
|
2010-06-08 16:52:24 +00:00
|
|
|
//
|
2016-03-02 02:18:18 +00:00
|
|
|
// RETURNS the non-nullptr buffer pointer upon successful extraction of
|
2018-04-30 16:49:04 +00:00
|
|
|
// all the requested bytes, or nullptr when the data is not available in the
|
|
|
|
|
// buffer due to being out of bounds, or insufficient data.
|
2013-01-25 18:06:21 +00:00
|
|
|
void *DataExtractor::GetU8(offset_t *offset_ptr, void *dst,
|
|
|
|
|
uint32_t count) const {
|
2019-05-23 05:12:11 +00:00
|
|
|
const uint8_t *data =
|
|
|
|
|
static_cast<const uint8_t *>(GetData(offset_ptr, count));
|
2013-02-08 22:02:02 +00:00
|
|
|
if (data) {
|
2010-06-08 16:52:24 +00:00
|
|
|
// Copy the data into the buffer
|
2013-02-08 22:02:02 +00:00
|
|
|
memcpy(dst, data, count);
|
2016-03-02 02:18:18 +00:00
|
|
|
// Return a non-nullptr pointer to the converted data as an indicator of
|
|
|
|
|
// success
|
2010-06-08 16:52:24 +00:00
|
|
|
return dst;
|
|
|
|
|
}
|
2016-03-02 02:18:18 +00:00
|
|
|
return nullptr;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// Extract a single uint16_t from the data and update the offset pointed to by
|
|
|
|
|
// "offset_ptr".
|
2010-06-08 16:52:24 +00:00
|
|
|
//
|
|
|
|
|
// RETURNS the uint16_t that was extracted, or zero on failure.
|
2013-01-25 18:06:21 +00:00
|
|
|
uint16_t DataExtractor::GetU16(offset_t *offset_ptr) const {
|
2010-06-08 16:52:24 +00:00
|
|
|
uint16_t val = 0;
|
2019-05-23 05:12:11 +00:00
|
|
|
const uint8_t *data =
|
|
|
|
|
static_cast<const uint8_t *>(GetData(offset_ptr, sizeof(val)));
|
2013-02-08 22:02:02 +00:00
|
|
|
if (data) {
|
2015-11-07 04:40:13 +00:00
|
|
|
if (m_byte_order != endian::InlHostByteOrder())
|
2013-02-08 22:02:02 +00:00
|
|
|
val = ReadSwapInt16(data);
|
2010-06-08 16:52:24 +00:00
|
|
|
else
|
2013-02-08 22:02:02 +00:00
|
|
|
val = ReadInt16(data);
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
return val;
|
|
|
|
|
}
|
|
|
|
|
|
2013-01-25 18:06:21 +00:00
|
|
|
uint16_t DataExtractor::GetU16_unchecked(offset_t *offset_ptr) const {
|
2013-02-08 22:02:02 +00:00
|
|
|
uint16_t val;
|
2015-11-07 04:40:13 +00:00
|
|
|
if (m_byte_order == endian::InlHostByteOrder())
|
2013-02-08 22:02:02 +00:00
|
|
|
val = ReadInt16(m_start, *offset_ptr);
|
|
|
|
|
else
|
|
|
|
|
val = ReadSwapInt16(m_start, *offset_ptr);
|
2010-09-15 08:33:30 +00:00
|
|
|
*offset_ptr += sizeof(val);
|
|
|
|
|
return val;
|
|
|
|
|
}
|
|
|
|
|
|
2013-01-25 18:06:21 +00:00
|
|
|
uint32_t DataExtractor::GetU32_unchecked(offset_t *offset_ptr) const {
|
2013-02-08 22:02:02 +00:00
|
|
|
uint32_t val;
|
2015-11-07 04:40:13 +00:00
|
|
|
if (m_byte_order == endian::InlHostByteOrder())
|
2013-02-08 22:02:02 +00:00
|
|
|
val = ReadInt32(m_start, *offset_ptr);
|
|
|
|
|
else
|
|
|
|
|
val = ReadSwapInt32(m_start, *offset_ptr);
|
2010-09-15 08:33:30 +00:00
|
|
|
*offset_ptr += sizeof(val);
|
|
|
|
|
return val;
|
|
|
|
|
}
|
|
|
|
|
|
2013-01-25 18:06:21 +00:00
|
|
|
uint64_t DataExtractor::GetU64_unchecked(offset_t *offset_ptr) const {
|
2013-02-08 22:02:02 +00:00
|
|
|
uint64_t val;
|
2015-11-07 04:40:13 +00:00
|
|
|
if (m_byte_order == endian::InlHostByteOrder())
|
2013-02-08 22:02:02 +00:00
|
|
|
val = ReadInt64(m_start, *offset_ptr);
|
|
|
|
|
else
|
|
|
|
|
val = ReadSwapInt64(m_start, *offset_ptr);
|
2010-09-15 08:33:30 +00:00
|
|
|
*offset_ptr += sizeof(val);
|
|
|
|
|
return val;
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// Extract "count" uint16_t values from the binary data and update the offset
|
|
|
|
|
// pointed to by "offset_ptr". The extracted data is copied into "dst".
|
2010-06-08 16:52:24 +00:00
|
|
|
//
|
2016-03-02 02:18:18 +00:00
|
|
|
// RETURNS the non-nullptr buffer pointer upon successful extraction of
|
2018-04-30 16:49:04 +00:00
|
|
|
// all the requested bytes, or nullptr when the data is not available in the
|
|
|
|
|
// buffer due to being out of bounds, or insufficient data.
|
2013-01-25 18:06:21 +00:00
|
|
|
void *DataExtractor::GetU16(offset_t *offset_ptr, void *void_dst,
|
|
|
|
|
uint32_t count) const {
|
2013-02-08 22:02:02 +00:00
|
|
|
const size_t src_size = sizeof(uint16_t) * count;
|
2019-05-23 05:12:11 +00:00
|
|
|
const uint16_t *src =
|
|
|
|
|
static_cast<const uint16_t *>(GetData(offset_ptr, src_size));
|
2013-02-08 22:02:02 +00:00
|
|
|
if (src) {
|
2015-11-07 04:40:13 +00:00
|
|
|
if (m_byte_order != endian::InlHostByteOrder()) {
|
2019-05-23 05:12:11 +00:00
|
|
|
uint16_t *dst_pos = static_cast<uint16_t *>(void_dst);
|
2013-02-08 22:02:02 +00:00
|
|
|
uint16_t *dst_end = dst_pos + count;
|
|
|
|
|
const uint16_t *src_pos = src;
|
|
|
|
|
while (dst_pos < dst_end) {
|
|
|
|
|
*dst_pos = ReadSwapInt16(src_pos);
|
|
|
|
|
++dst_pos;
|
|
|
|
|
++src_pos;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
} else {
|
2013-02-08 22:02:02 +00:00
|
|
|
memcpy(void_dst, src, src_size);
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
2016-03-02 02:18:18 +00:00
|
|
|
// Return a non-nullptr pointer to the converted data as an indicator of
|
|
|
|
|
// success
|
2013-02-08 22:02:02 +00:00
|
|
|
return void_dst;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2016-03-02 02:18:18 +00:00
|
|
|
return nullptr;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// Extract a single uint32_t from the data and update the offset pointed to by
|
|
|
|
|
// "offset_ptr".
|
2010-06-08 16:52:24 +00:00
|
|
|
//
|
|
|
|
|
// RETURNS the uint32_t that was extracted, or zero on failure.
|
2013-01-25 18:06:21 +00:00
|
|
|
uint32_t DataExtractor::GetU32(offset_t *offset_ptr) const {
|
2010-06-08 16:52:24 +00:00
|
|
|
uint32_t val = 0;
|
2019-05-23 05:12:11 +00:00
|
|
|
const uint8_t *data =
|
|
|
|
|
static_cast<const uint8_t *>(GetData(offset_ptr, sizeof(val)));
|
2013-02-08 22:02:02 +00:00
|
|
|
if (data) {
|
2015-11-07 04:40:13 +00:00
|
|
|
if (m_byte_order != endian::InlHostByteOrder()) {
|
2013-02-08 22:02:02 +00:00
|
|
|
val = ReadSwapInt32(data);
|
2010-06-08 16:52:24 +00:00
|
|
|
} else {
|
2014-01-25 05:12:35 +00:00
|
|
|
memcpy(&val, data, 4);
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
return val;
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// Extract "count" uint32_t values from the binary data and update the offset
|
|
|
|
|
// pointed to by "offset_ptr". The extracted data is copied into "dst".
|
2010-06-08 16:52:24 +00:00
|
|
|
//
|
2016-03-02 02:18:18 +00:00
|
|
|
// RETURNS the non-nullptr buffer pointer upon successful extraction of
|
2018-04-30 16:49:04 +00:00
|
|
|
// all the requested bytes, or nullptr when the data is not available in the
|
|
|
|
|
// buffer due to being out of bounds, or insufficient data.
|
2013-01-25 18:06:21 +00:00
|
|
|
void *DataExtractor::GetU32(offset_t *offset_ptr, void *void_dst,
|
|
|
|
|
uint32_t count) const {
|
2013-02-08 22:02:02 +00:00
|
|
|
const size_t src_size = sizeof(uint32_t) * count;
|
2019-05-23 05:12:11 +00:00
|
|
|
const uint32_t *src =
|
|
|
|
|
static_cast<const uint32_t *>(GetData(offset_ptr, src_size));
|
2013-02-08 22:02:02 +00:00
|
|
|
if (src) {
|
2015-11-07 04:40:13 +00:00
|
|
|
if (m_byte_order != endian::InlHostByteOrder()) {
|
2019-05-23 05:12:11 +00:00
|
|
|
uint32_t *dst_pos = static_cast<uint32_t *>(void_dst);
|
2013-02-08 22:02:02 +00:00
|
|
|
uint32_t *dst_end = dst_pos + count;
|
|
|
|
|
const uint32_t *src_pos = src;
|
|
|
|
|
while (dst_pos < dst_end) {
|
|
|
|
|
*dst_pos = ReadSwapInt32(src_pos);
|
|
|
|
|
++dst_pos;
|
|
|
|
|
++src_pos;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
} else {
|
2013-02-08 22:02:02 +00:00
|
|
|
memcpy(void_dst, src, src_size);
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
2016-03-02 02:18:18 +00:00
|
|
|
// Return a non-nullptr pointer to the converted data as an indicator of
|
|
|
|
|
// success
|
2013-02-08 22:02:02 +00:00
|
|
|
return void_dst;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2016-03-02 02:18:18 +00:00
|
|
|
return nullptr;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// Extract a single uint64_t from the data and update the offset pointed to by
|
|
|
|
|
// "offset_ptr".
|
2010-06-08 16:52:24 +00:00
|
|
|
//
|
|
|
|
|
// RETURNS the uint64_t that was extracted, or zero on failure.
|
2013-01-25 18:06:21 +00:00
|
|
|
uint64_t DataExtractor::GetU64(offset_t *offset_ptr) const {
|
2010-06-08 16:52:24 +00:00
|
|
|
uint64_t val = 0;
|
2019-05-23 05:12:11 +00:00
|
|
|
const uint8_t *data =
|
|
|
|
|
static_cast<const uint8_t *>(GetData(offset_ptr, sizeof(val)));
|
2013-02-08 22:02:02 +00:00
|
|
|
if (data) {
|
2015-11-07 04:40:13 +00:00
|
|
|
if (m_byte_order != endian::InlHostByteOrder()) {
|
2013-02-08 22:02:02 +00:00
|
|
|
val = ReadSwapInt64(data);
|
2010-06-08 16:52:24 +00:00
|
|
|
} else {
|
2014-01-25 05:12:35 +00:00
|
|
|
memcpy(&val, data, 8);
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
return val;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// GetU64
|
|
|
|
|
//
|
2018-04-30 16:49:04 +00:00
|
|
|
// Get multiple consecutive 64 bit values. Return true if the entire read
|
|
|
|
|
// succeeds and increment the offset pointed to by offset_ptr, else return
|
|
|
|
|
// false and leave the offset pointed to by offset_ptr unchanged.
|
2013-01-25 18:06:21 +00:00
|
|
|
void *DataExtractor::GetU64(offset_t *offset_ptr, void *void_dst,
|
|
|
|
|
uint32_t count) const {
|
2013-02-08 22:02:02 +00:00
|
|
|
const size_t src_size = sizeof(uint64_t) * count;
|
2019-05-23 05:12:11 +00:00
|
|
|
const uint64_t *src =
|
|
|
|
|
static_cast<const uint64_t *>(GetData(offset_ptr, src_size));
|
2013-02-08 22:02:02 +00:00
|
|
|
if (src) {
|
2015-11-07 04:40:13 +00:00
|
|
|
if (m_byte_order != endian::InlHostByteOrder()) {
|
2019-05-23 05:12:11 +00:00
|
|
|
uint64_t *dst_pos = static_cast<uint64_t *>(void_dst);
|
2013-02-08 22:02:02 +00:00
|
|
|
uint64_t *dst_end = dst_pos + count;
|
|
|
|
|
const uint64_t *src_pos = src;
|
|
|
|
|
while (dst_pos < dst_end) {
|
|
|
|
|
*dst_pos = ReadSwapInt64(src_pos);
|
|
|
|
|
++dst_pos;
|
|
|
|
|
++src_pos;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
} else {
|
2013-02-08 22:02:02 +00:00
|
|
|
memcpy(void_dst, src, src_size);
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
2016-03-02 02:18:18 +00:00
|
|
|
// Return a non-nullptr pointer to the converted data as an indicator of
|
|
|
|
|
// success
|
2013-02-08 22:02:02 +00:00
|
|
|
return void_dst;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2016-03-02 02:18:18 +00:00
|
|
|
return nullptr;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
2013-01-25 18:06:21 +00:00
|
|
|
uint32_t DataExtractor::GetMaxU32(offset_t *offset_ptr,
|
|
|
|
|
size_t byte_size) const {
|
2017-10-11 08:48:18 +00:00
|
|
|
lldbassert(byte_size > 0 && byte_size <= 4 && "GetMaxU32 invalid byte_size!");
|
|
|
|
|
return GetMaxU64(offset_ptr, byte_size);
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
2017-10-11 08:48:18 +00:00
|
|
|
uint64_t DataExtractor::GetMaxU64(offset_t *offset_ptr,
|
|
|
|
|
size_t byte_size) const {
|
|
|
|
|
lldbassert(byte_size > 0 && byte_size <= 8 && "GetMaxU64 invalid byte_size!");
|
|
|
|
|
switch (byte_size) {
|
2010-06-08 16:52:24 +00:00
|
|
|
case 1:
|
|
|
|
|
return GetU8(offset_ptr);
|
|
|
|
|
case 2:
|
|
|
|
|
return GetU16(offset_ptr);
|
|
|
|
|
case 4:
|
|
|
|
|
return GetU32(offset_ptr);
|
|
|
|
|
case 8:
|
|
|
|
|
return GetU64(offset_ptr);
|
2017-10-11 08:48:18 +00:00
|
|
|
default: {
|
|
|
|
|
// General case.
|
|
|
|
|
const uint8_t *data =
|
|
|
|
|
static_cast<const uint8_t *>(GetData(offset_ptr, byte_size));
|
|
|
|
|
if (data == nullptr)
|
|
|
|
|
return 0;
|
|
|
|
|
return ReadMaxInt64(data, byte_size, m_byte_order);
|
|
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-01-25 18:06:21 +00:00
|
|
|
uint64_t DataExtractor::GetMaxU64_unchecked(offset_t *offset_ptr,
|
2017-10-11 08:48:18 +00:00
|
|
|
size_t byte_size) const {
|
|
|
|
|
switch (byte_size) {
|
2011-12-30 00:32:24 +00:00
|
|
|
case 1:
|
|
|
|
|
return GetU8_unchecked(offset_ptr);
|
|
|
|
|
case 2:
|
|
|
|
|
return GetU16_unchecked(offset_ptr);
|
|
|
|
|
case 4:
|
|
|
|
|
return GetU32_unchecked(offset_ptr);
|
|
|
|
|
case 8:
|
|
|
|
|
return GetU64_unchecked(offset_ptr);
|
2017-10-11 08:48:18 +00:00
|
|
|
default: {
|
|
|
|
|
uint64_t res = ReadMaxInt64(&m_start[*offset_ptr], byte_size, m_byte_order);
|
|
|
|
|
*offset_ptr += byte_size;
|
|
|
|
|
return res;
|
|
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2017-10-11 08:48:18 +00:00
|
|
|
int64_t DataExtractor::GetMaxS64(offset_t *offset_ptr, size_t byte_size) const {
|
|
|
|
|
uint64_t u64 = GetMaxU64(offset_ptr, byte_size);
|
|
|
|
|
return llvm::SignExtend64(u64, 8 * byte_size);
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-01-25 18:06:21 +00:00
|
|
|
uint64_t DataExtractor::GetMaxU64Bitfield(offset_t *offset_ptr, size_t size,
|
|
|
|
|
uint32_t bitfield_bit_size,
|
|
|
|
|
uint32_t bitfield_bit_offset) const {
|
2010-06-08 16:52:24 +00:00
|
|
|
uint64_t uval64 = GetMaxU64(offset_ptr, size);
|
|
|
|
|
if (bitfield_bit_size > 0) {
|
Handle bit fields on big-endian systems correctly
Currently, the DataExtractor::GetMaxU64Bitfield and GetMaxS64Bitfield
routines assume the incoming "bitfield_bit_offset" parameter uses
little-endian bit numbering, i.e. a bitfield_bit_offset 0 refers to
a bitfield whose least-significant bit coincides with the least-
significant bit of the surrounding integer.
On many big-endian systems, however, the big-endian bit numbering
is used for bit fields. Here, a bitfield_bit_offset 0 refers to
a bitfield whose most-significant bit conincides with the most-
significant bit of the surrounding integer.
Now, in principle LLDB could arbitrarily choose which semantics of
bitfield_bit_offset to use. However, there are two problems with
the current approach:
- When parsing DWARF, LLDB decodes bit offsets in little-endian
bit numbering on LE systems, but in big-endian bit numbering
on BE systems. Passing those offsets later on into the
DataExtractor routines gives incorrect results on BE.
- In the interim, LLDB's type layer combines byte and bit offsets
into a single number. I.e. instead of recording bitfields by
specifying the byte offset and byte size of the surrounding
integer *plus* the bit offset of the bit field within that field,
it simply records a single bit offset number.
Now, note that converting from byte offset + bit offset to a
single offset value and back is well-defined if we either use
little-endian byte order *and* little-endian bit numbering,
or use big-endian byte order *and* big-endian bit numbering.
Any other combination will yield incorrect results.
Therefore, the simplest approach would seem to be to always use
the bit numbering that matches the system byte order. This makes
storing a single bit offset valid, and makes the existing DWARF
code correct. The only place to fix is to teach DataExtractor
to use big-endian bit numbering on big endian systems.
However, there is only additional caveat: we also get bit offsets
from LLDB synthetic bitfields. While the exact semantics of those
doesn't seem to be well-defined, from test cases it appears that
the intent was for the user-provided synthetic bitfield offset to
always use little-endian bit numbering. Therefore, on a big-endian
system we now have to convert those to big-endian bit numbering
to remain consistent.
Differential Revision: http://reviews.llvm.org/D18982
llvm-svn: 266312
2016-04-14 14:32:57 +00:00
|
|
|
int32_t lsbcount = bitfield_bit_offset;
|
2011-05-09 20:18:18 +00:00
|
|
|
if (m_byte_order == eByteOrderBig)
|
Handle bit fields on big-endian systems correctly
Currently, the DataExtractor::GetMaxU64Bitfield and GetMaxS64Bitfield
routines assume the incoming "bitfield_bit_offset" parameter uses
little-endian bit numbering, i.e. a bitfield_bit_offset 0 refers to
a bitfield whose least-significant bit coincides with the least-
significant bit of the surrounding integer.
On many big-endian systems, however, the big-endian bit numbering
is used for bit fields. Here, a bitfield_bit_offset 0 refers to
a bitfield whose most-significant bit conincides with the most-
significant bit of the surrounding integer.
Now, in principle LLDB could arbitrarily choose which semantics of
bitfield_bit_offset to use. However, there are two problems with
the current approach:
- When parsing DWARF, LLDB decodes bit offsets in little-endian
bit numbering on LE systems, but in big-endian bit numbering
on BE systems. Passing those offsets later on into the
DataExtractor routines gives incorrect results on BE.
- In the interim, LLDB's type layer combines byte and bit offsets
into a single number. I.e. instead of recording bitfields by
specifying the byte offset and byte size of the surrounding
integer *plus* the bit offset of the bit field within that field,
it simply records a single bit offset number.
Now, note that converting from byte offset + bit offset to a
single offset value and back is well-defined if we either use
little-endian byte order *and* little-endian bit numbering,
or use big-endian byte order *and* big-endian bit numbering.
Any other combination will yield incorrect results.
Therefore, the simplest approach would seem to be to always use
the bit numbering that matches the system byte order. This makes
storing a single bit offset valid, and makes the existing DWARF
code correct. The only place to fix is to teach DataExtractor
to use big-endian bit numbering on big endian systems.
However, there is only additional caveat: we also get bit offsets
from LLDB synthetic bitfields. While the exact semantics of those
doesn't seem to be well-defined, from test cases it appears that
the intent was for the user-provided synthetic bitfield offset to
always use little-endian bit numbering. Therefore, on a big-endian
system we now have to convert those to big-endian bit numbering
to remain consistent.
Differential Revision: http://reviews.llvm.org/D18982
llvm-svn: 266312
2016-04-14 14:32:57 +00:00
|
|
|
lsbcount = size * 8 - bitfield_bit_offset - bitfield_bit_size;
|
|
|
|
|
if (lsbcount > 0)
|
|
|
|
|
uval64 >>= lsbcount;
|
2011-07-06 02:13:41 +00:00
|
|
|
uint64_t bitfield_mask = ((1ul << bitfield_bit_size) - 1);
|
The implementation of categories is now synchronization safe
Code cleanup:
- The Format Manager implementation is now split between two files: FormatClasses.{h|cpp} where the
actual formatter classes (ValueFormat, SummaryFormat, ...) are implemented and
FormatManager.{h|cpp} where the infrastructure classes (FormatNavigator, FormatManager, ...)
are contained. The wrapper code always remains in Debugger.{h|cpp}
- Several leftover fields, methods and comments from previous design choices have been removed
type category subcommands (enable, disable, delete) now can take a list of category names as input
- for type category enable, saying "enable A B C" is the same as saying
enable C
enable B
enable A
(the ordering is relevant in enabling categories, and it is expected that a user typing
enable A B C wants to look into category A, then into B, then into C and not the other
way round)
- for the other two commands, the order is not really relevant (however, the same inverted ordering
is used for consistency)
llvm-svn: 135494
2011-07-19 18:03:25 +00:00
|
|
|
if (!bitfield_mask && bitfield_bit_offset == 0 && bitfield_bit_size == 64)
|
2010-06-08 16:52:24 +00:00
|
|
|
return uval64;
|
|
|
|
|
uval64 &= bitfield_mask;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
return uval64;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2013-01-25 18:06:21 +00:00
|
|
|
int64_t DataExtractor::GetMaxS64Bitfield(offset_t *offset_ptr, size_t size,
|
Added support for the new ".apple_objc" accelerator tables. These tables are
in the same hashed format as the ".apple_names", but they map objective C
class names to all of the methods and class functions. We need to do this
because in the DWARF the methods for Objective C are never contained in the
class definition, they are scattered about at the translation unit level and
they don't even have attributes that say the are contained within the class
itself.
Added 3 new formats which can be used to display data:
eFormatAddressInfo
eFormatHexFloat
eFormatInstruction
eFormatAddressInfo describes an address such as function+offset and file+line,
or symbol + offset, or constant data (c string, 2, 4, 8, or 16 byte constants).
The format character for this is "A", the long format is "address".
eFormatHexFloat will print out the hex float format that compilers tend to use.
The format character for this is "X", the long format is "hex float".
eFormatInstruction will print out disassembly with bytes and it will use the
current target's architecture. The format character for this is "i" (which
used to be being used for the integer format, but the integer format also has
"d", so we gave the "i" format to disassembly), the long format is
"instruction".
Mate the lldb::FormatterChoiceCriterion enumeration private as it should have
been from the start. It is very specialized and doesn't belong in the public
API.
llvm-svn: 143114
2011-10-27 17:55:14 +00:00
|
|
|
uint32_t bitfield_bit_size,
|
2010-06-08 16:52:24 +00:00
|
|
|
uint32_t bitfield_bit_offset) const {
|
|
|
|
|
int64_t sval64 = GetMaxS64(offset_ptr, size);
|
|
|
|
|
if (bitfield_bit_size > 0) {
|
Handle bit fields on big-endian systems correctly
Currently, the DataExtractor::GetMaxU64Bitfield and GetMaxS64Bitfield
routines assume the incoming "bitfield_bit_offset" parameter uses
little-endian bit numbering, i.e. a bitfield_bit_offset 0 refers to
a bitfield whose least-significant bit coincides with the least-
significant bit of the surrounding integer.
On many big-endian systems, however, the big-endian bit numbering
is used for bit fields. Here, a bitfield_bit_offset 0 refers to
a bitfield whose most-significant bit conincides with the most-
significant bit of the surrounding integer.
Now, in principle LLDB could arbitrarily choose which semantics of
bitfield_bit_offset to use. However, there are two problems with
the current approach:
- When parsing DWARF, LLDB decodes bit offsets in little-endian
bit numbering on LE systems, but in big-endian bit numbering
on BE systems. Passing those offsets later on into the
DataExtractor routines gives incorrect results on BE.
- In the interim, LLDB's type layer combines byte and bit offsets
into a single number. I.e. instead of recording bitfields by
specifying the byte offset and byte size of the surrounding
integer *plus* the bit offset of the bit field within that field,
it simply records a single bit offset number.
Now, note that converting from byte offset + bit offset to a
single offset value and back is well-defined if we either use
little-endian byte order *and* little-endian bit numbering,
or use big-endian byte order *and* big-endian bit numbering.
Any other combination will yield incorrect results.
Therefore, the simplest approach would seem to be to always use
the bit numbering that matches the system byte order. This makes
storing a single bit offset valid, and makes the existing DWARF
code correct. The only place to fix is to teach DataExtractor
to use big-endian bit numbering on big endian systems.
However, there is only additional caveat: we also get bit offsets
from LLDB synthetic bitfields. While the exact semantics of those
doesn't seem to be well-defined, from test cases it appears that
the intent was for the user-provided synthetic bitfield offset to
always use little-endian bit numbering. Therefore, on a big-endian
system we now have to convert those to big-endian bit numbering
to remain consistent.
Differential Revision: http://reviews.llvm.org/D18982
llvm-svn: 266312
2016-04-14 14:32:57 +00:00
|
|
|
int32_t lsbcount = bitfield_bit_offset;
|
|
|
|
|
if (m_byte_order == eByteOrderBig)
|
|
|
|
|
lsbcount = size * 8 - bitfield_bit_offset - bitfield_bit_size;
|
|
|
|
|
if (lsbcount > 0)
|
|
|
|
|
sval64 >>= lsbcount;
|
2019-05-23 05:12:11 +00:00
|
|
|
uint64_t bitfield_mask =
|
|
|
|
|
((static_cast<uint64_t>(1)) << bitfield_bit_size) - 1;
|
2010-06-08 16:52:24 +00:00
|
|
|
sval64 &= bitfield_mask;
|
|
|
|
|
// sign extend if needed
|
2019-05-23 05:12:11 +00:00
|
|
|
if (sval64 & ((static_cast<uint64_t>(1)) << (bitfield_bit_size - 1)))
|
2010-06-08 16:52:24 +00:00
|
|
|
sval64 |= ~bitfield_mask;
|
|
|
|
|
}
|
|
|
|
|
return sval64;
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-01-25 18:06:21 +00:00
|
|
|
float DataExtractor::GetFloat(offset_t *offset_ptr) const {
|
2010-09-14 04:09:57 +00:00
|
|
|
typedef float float_type;
|
|
|
|
|
float_type val = 0.0;
|
2013-02-08 22:02:02 +00:00
|
|
|
const size_t src_size = sizeof(float_type);
|
2019-05-23 05:12:11 +00:00
|
|
|
const float_type *src =
|
|
|
|
|
static_cast<const float_type *>(GetData(offset_ptr, src_size));
|
2013-02-08 22:02:02 +00:00
|
|
|
if (src) {
|
2015-11-07 04:40:13 +00:00
|
|
|
if (m_byte_order != endian::InlHostByteOrder()) {
|
2019-05-23 05:12:11 +00:00
|
|
|
const uint8_t *src_data = reinterpret_cast<const uint8_t *>(src);
|
|
|
|
|
uint8_t *dst_data = reinterpret_cast<uint8_t *>(&val);
|
2016-03-02 02:18:18 +00:00
|
|
|
for (size_t i = 0; i < sizeof(float_type); ++i)
|
2010-09-14 04:09:57 +00:00
|
|
|
dst_data[sizeof(float_type) - 1 - i] = src_data[i];
|
2010-06-08 16:52:24 +00:00
|
|
|
} else {
|
2013-02-08 22:02:02 +00:00
|
|
|
val = *src;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2010-09-14 04:09:57 +00:00
|
|
|
return val;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-01-25 18:06:21 +00:00
|
|
|
double DataExtractor::GetDouble(offset_t *offset_ptr) const {
|
2010-09-14 04:09:57 +00:00
|
|
|
typedef double float_type;
|
|
|
|
|
float_type val = 0.0;
|
2013-02-08 22:02:02 +00:00
|
|
|
const size_t src_size = sizeof(float_type);
|
2019-05-23 05:12:11 +00:00
|
|
|
const float_type *src =
|
|
|
|
|
static_cast<const float_type *>(GetData(offset_ptr, src_size));
|
2013-02-08 22:02:02 +00:00
|
|
|
if (src) {
|
2015-11-07 04:40:13 +00:00
|
|
|
if (m_byte_order != endian::InlHostByteOrder()) {
|
2019-05-23 05:12:11 +00:00
|
|
|
const uint8_t *src_data = reinterpret_cast<const uint8_t *>(src);
|
|
|
|
|
uint8_t *dst_data = reinterpret_cast<uint8_t *>(&val);
|
2016-03-02 02:18:18 +00:00
|
|
|
for (size_t i = 0; i < sizeof(float_type); ++i)
|
2010-09-14 04:09:57 +00:00
|
|
|
dst_data[sizeof(float_type) - 1 - i] = src_data[i];
|
2010-06-08 16:52:24 +00:00
|
|
|
} else {
|
2013-02-08 22:02:02 +00:00
|
|
|
val = *src;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2010-09-14 04:09:57 +00:00
|
|
|
return val;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
2013-01-25 18:06:21 +00:00
|
|
|
long double DataExtractor::GetLongDouble(offset_t *offset_ptr) const {
|
2013-08-19 19:39:03 +00:00
|
|
|
long double val = 0.0;
|
|
|
|
|
#if defined(__i386__) || defined(__amd64__) || defined(__x86_64__) || \
|
|
|
|
|
defined(_M_IX86) || defined(_M_IA64) || defined(_M_X64)
|
2015-11-07 04:40:13 +00:00
|
|
|
*offset_ptr += CopyByteOrderedData(*offset_ptr, 10, &val, sizeof(val),
|
|
|
|
|
endian::InlHostByteOrder());
|
2013-08-19 19:39:03 +00:00
|
|
|
#else
|
2015-11-07 04:40:13 +00:00
|
|
|
*offset_ptr += CopyByteOrderedData(*offset_ptr, sizeof(val), &val,
|
|
|
|
|
sizeof(val), endian::InlHostByteOrder());
|
2013-08-19 19:39:03 +00:00
|
|
|
#endif
|
2010-09-14 04:09:57 +00:00
|
|
|
return val;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// Extract a single address from the data and update the offset pointed to by
|
|
|
|
|
// "offset_ptr". The size of the extracted address comes from the
|
|
|
|
|
// "this->m_addr_size" member variable and should be set correctly prior to
|
|
|
|
|
// extracting any address values.
|
2010-06-08 16:52:24 +00:00
|
|
|
//
|
|
|
|
|
// RETURNS the address that was extracted, or zero on failure.
|
2013-01-25 18:06:21 +00:00
|
|
|
uint64_t DataExtractor::GetAddress(offset_t *offset_ptr) const {
|
2015-11-05 23:41:08 +00:00
|
|
|
assert(m_addr_size == 4 || m_addr_size == 8);
|
2010-06-08 16:52:24 +00:00
|
|
|
return GetMaxU64(offset_ptr, m_addr_size);
|
|
|
|
|
}
|
|
|
|
|
|
2013-01-25 18:06:21 +00:00
|
|
|
uint64_t DataExtractor::GetAddress_unchecked(offset_t *offset_ptr) const {
|
2015-11-05 23:41:08 +00:00
|
|
|
assert(m_addr_size == 4 || m_addr_size == 8);
|
2011-12-30 00:32:24 +00:00
|
|
|
return GetMaxU64_unchecked(offset_ptr, m_addr_size);
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// Extract a single pointer from the data and update the offset pointed to by
|
|
|
|
|
// "offset_ptr". The size of the extracted pointer comes from the
|
|
|
|
|
// "this->m_addr_size" member variable and should be set correctly prior to
|
|
|
|
|
// extracting any pointer values.
|
2010-06-08 16:52:24 +00:00
|
|
|
//
|
|
|
|
|
// RETURNS the pointer that was extracted, or zero on failure.
|
2013-01-25 18:06:21 +00:00
|
|
|
uint64_t DataExtractor::GetPointer(offset_t *offset_ptr) const {
|
2015-11-05 23:41:08 +00:00
|
|
|
assert(m_addr_size == 4 || m_addr_size == 8);
|
2010-06-08 16:52:24 +00:00
|
|
|
return GetMaxU64(offset_ptr, m_addr_size);
|
|
|
|
|
}
|
|
|
|
|
|
2013-01-25 18:06:21 +00:00
|
|
|
size_t DataExtractor::ExtractBytes(offset_t offset, offset_t length,
|
|
|
|
|
ByteOrder dst_byte_order, void *dst) const {
|
2010-06-08 16:52:24 +00:00
|
|
|
const uint8_t *src = PeekData(offset, length);
|
|
|
|
|
if (src) {
|
|
|
|
|
if (dst_byte_order != GetByteOrder()) {
|
2013-09-19 15:12:36 +00:00
|
|
|
// Validate that only a word- or register-sized dst is byte swapped
|
|
|
|
|
assert(length == 1 || length == 2 || length == 4 || length == 8 ||
|
|
|
|
|
length == 10 || length == 16 || length == 32);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2016-03-02 02:18:18 +00:00
|
|
|
for (uint32_t i = 0; i < length; ++i)
|
2019-05-23 05:12:11 +00:00
|
|
|
(static_cast<uint8_t *>(dst))[i] = src[length - i - 1];
|
2010-06-08 16:52:24 +00:00
|
|
|
} else
|
|
|
|
|
::memcpy(dst, src, length);
|
|
|
|
|
return length;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2013-10-09 20:34:25 +00:00
|
|
|
// Extract data as it exists in target memory
|
|
|
|
|
lldb::offset_t DataExtractor::CopyData(offset_t offset, offset_t length,
|
|
|
|
|
void *dst) const {
|
|
|
|
|
const uint8_t *src = PeekData(offset, length);
|
|
|
|
|
if (src) {
|
|
|
|
|
::memcpy(dst, src, length);
|
|
|
|
|
return length;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2011-05-09 20:18:18 +00:00
|
|
|
// Extract data and swap if needed when doing the copy
|
2013-01-25 18:06:21 +00:00
|
|
|
lldb::offset_t
|
|
|
|
|
DataExtractor::CopyByteOrderedData(offset_t src_offset, offset_t src_len,
|
2011-05-09 20:18:18 +00:00
|
|
|
void *dst_void_ptr, offset_t dst_len,
|
|
|
|
|
ByteOrder dst_byte_order) const {
|
|
|
|
|
// Validate the source info
|
2013-01-25 18:06:21 +00:00
|
|
|
if (!ValidOffsetForDataOfSize(src_offset, src_len))
|
|
|
|
|
assert(ValidOffsetForDataOfSize(src_offset, src_len));
|
2011-05-09 20:18:18 +00:00
|
|
|
assert(src_len > 0);
|
|
|
|
|
assert(m_byte_order == eByteOrderBig || m_byte_order == eByteOrderLittle);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-05-09 20:18:18 +00:00
|
|
|
// Validate the destination info
|
2016-03-02 02:18:18 +00:00
|
|
|
assert(dst_void_ptr != nullptr);
|
2011-05-09 20:18:18 +00:00
|
|
|
assert(dst_len > 0);
|
|
|
|
|
assert(dst_byte_order == eByteOrderBig || dst_byte_order == eByteOrderLittle);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-09-19 15:12:36 +00:00
|
|
|
// Validate that only a word- or register-sized dst is byte swapped
|
|
|
|
|
assert(dst_byte_order == m_byte_order || dst_len == 1 || dst_len == 2 ||
|
|
|
|
|
dst_len == 4 || dst_len == 8 || dst_len == 10 || dst_len == 16 ||
|
|
|
|
|
dst_len == 32);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-05-09 20:18:18 +00:00
|
|
|
// Must have valid byte orders set in this object and for destination
|
|
|
|
|
if (!(dst_byte_order == eByteOrderBig ||
|
|
|
|
|
dst_byte_order == eByteOrderLittle) ||
|
|
|
|
|
!(m_byte_order == eByteOrderBig || m_byte_order == eByteOrderLittle))
|
|
|
|
|
return 0;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-05-23 05:12:11 +00:00
|
|
|
uint8_t *dst = static_cast<uint8_t *>(dst_void_ptr);
|
|
|
|
|
const uint8_t *src = PeekData(src_offset, src_len);
|
2016-09-06 20:57:50 +00:00
|
|
|
if (src) {
|
2011-05-09 20:18:18 +00:00
|
|
|
if (dst_len >= src_len) {
|
2018-04-30 16:49:04 +00:00
|
|
|
// We are copying the entire value from src into dst. Calculate how many,
|
|
|
|
|
// if any, zeroes we need for the most significant bytes if "dst_len" is
|
|
|
|
|
// greater than "src_len"...
|
2011-05-09 20:18:18 +00:00
|
|
|
const size_t num_zeroes = dst_len - src_len;
|
|
|
|
|
if (dst_byte_order == eByteOrderBig) {
|
|
|
|
|
// Big endian, so we lead with zeroes...
|
|
|
|
|
if (num_zeroes > 0)
|
|
|
|
|
::memset(dst, 0, num_zeroes);
|
|
|
|
|
// Then either copy or swap the rest
|
|
|
|
|
if (m_byte_order == eByteOrderBig) {
|
|
|
|
|
::memcpy(dst + num_zeroes, src, src_len);
|
|
|
|
|
} else {
|
2016-03-02 02:18:18 +00:00
|
|
|
for (uint32_t i = 0; i < src_len; ++i)
|
2011-05-09 20:18:18 +00:00
|
|
|
dst[i + num_zeroes] = src[src_len - 1 - i];
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
// Little endian destination, so we lead the value bytes
|
|
|
|
|
if (m_byte_order == eByteOrderBig) {
|
2016-03-02 02:18:18 +00:00
|
|
|
for (uint32_t i = 0; i < src_len; ++i)
|
2013-01-25 18:06:21 +00:00
|
|
|
dst[i] = src[src_len - 1 - i];
|
2016-09-06 20:57:50 +00:00
|
|
|
} else {
|
2011-05-09 20:18:18 +00:00
|
|
|
::memcpy(dst, src, src_len);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2011-05-09 20:18:18 +00:00
|
|
|
// And zero the rest...
|
|
|
|
|
if (num_zeroes > 0)
|
|
|
|
|
::memset(dst + src_len, 0, num_zeroes);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2011-05-09 20:18:18 +00:00
|
|
|
return src_len;
|
|
|
|
|
} else {
|
|
|
|
|
// We are only copying some of the value from src into dst..
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-09-17 17:51:33 +00:00
|
|
|
if (dst_byte_order == eByteOrderBig) {
|
2011-05-09 20:18:18 +00:00
|
|
|
// Big endian dst
|
|
|
|
|
if (m_byte_order == eByteOrderBig) {
|
|
|
|
|
// Big endian dst, with big endian src
|
|
|
|
|
::memcpy(dst, src + (src_len - dst_len), dst_len);
|
|
|
|
|
} else {
|
|
|
|
|
// Big endian dst, with little endian src
|
2016-03-02 02:18:18 +00:00
|
|
|
for (uint32_t i = 0; i < dst_len; ++i)
|
2011-05-09 20:18:18 +00:00
|
|
|
dst[i] = src[dst_len - 1 - i];
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
// Little endian dst
|
|
|
|
|
if (m_byte_order == eByteOrderBig) {
|
|
|
|
|
// Little endian dst, with big endian src
|
2016-03-02 02:18:18 +00:00
|
|
|
for (uint32_t i = 0; i < dst_len; ++i)
|
2011-05-09 20:18:18 +00:00
|
|
|
dst[i] = src[src_len - 1 - i];
|
|
|
|
|
} else {
|
|
|
|
|
// Little endian dst, with big endian src
|
|
|
|
|
::memcpy(dst, src, dst_len);
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2011-05-09 20:18:18 +00:00
|
|
|
return dst_len;
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2011-05-09 20:18:18 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// Extracts a variable length NULL terminated C string from the data at the
|
|
|
|
|
// offset pointed to by "offset_ptr". The "offset_ptr" will be updated with
|
|
|
|
|
// the offset of the byte that follows the NULL terminator byte.
|
2010-06-08 16:52:24 +00:00
|
|
|
//
|
2018-04-30 16:49:04 +00:00
|
|
|
// If the offset pointed to by "offset_ptr" is out of bounds, or if "length" is
|
|
|
|
|
// non-zero and there aren't enough available bytes, nullptr will be returned
|
|
|
|
|
// and "offset_ptr" will not be updated.
|
2013-01-25 18:06:21 +00:00
|
|
|
const char *DataExtractor::GetCStr(offset_t *offset_ptr) const {
|
2019-10-10 11:15:38 +00:00
|
|
|
const char *start = reinterpret_cast<const char *>(PeekData(*offset_ptr, 1));
|
|
|
|
|
// Already at the end of the data.
|
|
|
|
|
if (!start)
|
|
|
|
|
return nullptr;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-10-10 11:15:38 +00:00
|
|
|
const char *end = reinterpret_cast<const char *>(m_end);
|
|
|
|
|
|
|
|
|
|
// Check all bytes for a null terminator that terminates a C string.
|
|
|
|
|
const char *terminator_or_end = std::find(start, end, '\0');
|
|
|
|
|
|
|
|
|
|
// We didn't find a null terminator, so return nullptr to indicate that there
|
|
|
|
|
// is no valid C string at that offset.
|
|
|
|
|
if (terminator_or_end == end)
|
|
|
|
|
return nullptr;
|
|
|
|
|
|
|
|
|
|
// Update offset_ptr for the caller to point to the data behind the
|
|
|
|
|
// terminator (which is 1 byte long).
|
|
|
|
|
*offset_ptr += (terminator_or_end - start + 1UL);
|
|
|
|
|
return start;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// Extracts a NULL terminated C string from the fixed length field of length
|
|
|
|
|
// "len" at the offset pointed to by "offset_ptr". The "offset_ptr" will be
|
|
|
|
|
// updated with the offset of the byte that follows the fixed length field.
|
2013-07-23 18:22:17 +00:00
|
|
|
//
|
2018-04-30 16:49:04 +00:00
|
|
|
// If the offset pointed to by "offset_ptr" is out of bounds, or if the offset
|
|
|
|
|
// plus the length of the field is out of bounds, or if the field does not
|
|
|
|
|
// contain a NULL terminator byte, nullptr will be returned and "offset_ptr"
|
|
|
|
|
// will not be updated.
|
2013-07-23 18:22:17 +00:00
|
|
|
const char *DataExtractor::GetCStr(offset_t *offset_ptr, offset_t len) const {
|
2019-05-23 05:12:11 +00:00
|
|
|
const char *cstr = reinterpret_cast<const char *>(PeekData(*offset_ptr, len));
|
2016-03-02 02:18:18 +00:00
|
|
|
if (cstr != nullptr) {
|
|
|
|
|
if (memchr(cstr, '\0', len) == nullptr) {
|
|
|
|
|
return nullptr;
|
2013-07-23 18:22:17 +00:00
|
|
|
}
|
|
|
|
|
*offset_ptr += len;
|
|
|
|
|
return cstr;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2016-03-02 02:18:18 +00:00
|
|
|
return nullptr;
|
2013-07-23 18:22:17 +00:00
|
|
|
}
|
|
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// Peeks at a string in the contained data. No verification is done to make
|
|
|
|
|
// sure the entire string lies within the bounds of this object's data, only
|
|
|
|
|
// "offset" is verified to be a valid offset.
|
2010-06-08 16:52:24 +00:00
|
|
|
//
|
2018-04-30 16:49:04 +00:00
|
|
|
// Returns a valid C string pointer if "offset" is a valid offset in this
|
|
|
|
|
// object's data, else nullptr is returned.
|
2013-01-25 18:06:21 +00:00
|
|
|
const char *DataExtractor::PeekCStr(offset_t offset) const {
|
2019-05-23 05:12:11 +00:00
|
|
|
return reinterpret_cast<const char *>(PeekData(offset, 1));
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// Extracts an unsigned LEB128 number from this object's data starting at the
|
|
|
|
|
// offset pointed to by "offset_ptr". The offset pointed to by "offset_ptr"
|
|
|
|
|
// will be updated with the offset of the byte following the last extracted
|
|
|
|
|
// byte.
|
2010-06-08 16:52:24 +00:00
|
|
|
//
|
|
|
|
|
// Returned the extracted integer value.
|
2013-01-25 18:06:21 +00:00
|
|
|
uint64_t DataExtractor::GetULEB128(offset_t *offset_ptr) const {
|
2019-05-23 05:12:11 +00:00
|
|
|
const uint8_t *src = PeekData(*offset_ptr, 1);
|
2011-11-14 22:56:58 +00:00
|
|
|
if (src == nullptr)
|
|
|
|
|
return 0;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-02-08 22:02:02 +00:00
|
|
|
const uint8_t *end = m_end;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-11-14 22:56:58 +00:00
|
|
|
if (src < end) {
|
|
|
|
|
uint64_t result = *src++;
|
|
|
|
|
if (result >= 0x80) {
|
|
|
|
|
result &= 0x7f;
|
|
|
|
|
int shift = 7;
|
|
|
|
|
while (src < end) {
|
|
|
|
|
uint8_t byte = *src++;
|
2019-05-23 05:12:11 +00:00
|
|
|
result |= static_cast<uint64_t>(byte & 0x7f) << shift;
|
2010-06-08 16:52:24 +00:00
|
|
|
if ((byte & 0x80) == 0)
|
2016-09-06 20:57:50 +00:00
|
|
|
break;
|
2011-11-14 22:56:58 +00:00
|
|
|
shift += 7;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
}
|
2013-02-08 22:02:02 +00:00
|
|
|
*offset_ptr = src - m_start;
|
2011-11-14 22:56:58 +00:00
|
|
|
return result;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2011-05-09 20:18:18 +00:00
|
|
|
return 0;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// Extracts an signed LEB128 number from this object's data starting at the
|
|
|
|
|
// offset pointed to by "offset_ptr". The offset pointed to by "offset_ptr"
|
|
|
|
|
// will be updated with the offset of the byte following the last extracted
|
|
|
|
|
// byte.
|
2010-06-08 16:52:24 +00:00
|
|
|
//
|
|
|
|
|
// Returned the extracted integer value.
|
2013-01-25 18:06:21 +00:00
|
|
|
int64_t DataExtractor::GetSLEB128(offset_t *offset_ptr) const {
|
2019-05-23 05:12:11 +00:00
|
|
|
const uint8_t *src = PeekData(*offset_ptr, 1);
|
2016-03-02 02:18:18 +00:00
|
|
|
if (src == nullptr)
|
2013-05-15 18:27:08 +00:00
|
|
|
return 0;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2010-07-09 20:39:50 +00:00
|
|
|
const uint8_t *end = m_end;
|
2010-06-08 16:52:24 +00:00
|
|
|
|
|
|
|
|
if (src < end) {
|
|
|
|
|
int64_t result = 0;
|
|
|
|
|
int shift = 0;
|
|
|
|
|
int size = sizeof(int64_t) * 8;
|
|
|
|
|
|
2011-11-14 22:56:58 +00:00
|
|
|
uint8_t byte = 0;
|
2010-06-08 16:52:24 +00:00
|
|
|
int bytecount = 0;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-11-14 22:56:58 +00:00
|
|
|
while (src < end) {
|
2010-06-08 16:52:24 +00:00
|
|
|
bytecount++;
|
|
|
|
|
byte = *src++;
|
2019-05-23 05:12:11 +00:00
|
|
|
result |= static_cast<int64_t>(byte & 0x7f) << shift;
|
2011-11-14 22:56:58 +00:00
|
|
|
shift += 7;
|
2010-06-08 16:52:24 +00:00
|
|
|
if ((byte & 0x80) == 0)
|
2013-02-08 22:02:02 +00:00
|
|
|
break;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
// Sign bit of byte is 2nd high order bit (0x40)
|
|
|
|
|
if (shift < size && (byte & 0x40))
|
2016-06-28 17:14:18 +00:00
|
|
|
result |= -(1 << shift);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-06-11 21:56:55 +00:00
|
|
|
*offset_ptr += bytecount;
|
2011-11-14 22:56:58 +00:00
|
|
|
return result;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2013-02-08 22:02:02 +00:00
|
|
|
return 0;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// Skips a ULEB128 number (signed or unsigned) from this object's data starting
|
|
|
|
|
// at the offset pointed to by "offset_ptr". The offset pointed to by
|
|
|
|
|
// "offset_ptr" will be updated with the offset of the byte following the last
|
|
|
|
|
// extracted byte.
|
2010-06-08 16:52:24 +00:00
|
|
|
//
|
|
|
|
|
// Returns the number of bytes consumed during the extraction.
|
2013-01-25 18:06:21 +00:00
|
|
|
uint32_t DataExtractor::Skip_LEB128(offset_t *offset_ptr) const {
|
2010-06-08 16:52:24 +00:00
|
|
|
uint32_t bytes_consumed = 0;
|
2019-05-23 05:12:11 +00:00
|
|
|
const uint8_t *src = PeekData(*offset_ptr, 1);
|
2016-03-02 02:18:18 +00:00
|
|
|
if (src == nullptr)
|
2010-06-08 16:52:24 +00:00
|
|
|
return 0;
|
|
|
|
|
|
2013-06-11 21:56:55 +00:00
|
|
|
const uint8_t *end = m_end;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-06-11 21:56:55 +00:00
|
|
|
if (src < end) {
|
|
|
|
|
const uint8_t *src_pos = src;
|
2011-08-15 02:24:40 +00:00
|
|
|
while ((src_pos < end) && (*src_pos++ & 0x80))
|
|
|
|
|
++bytes_consumed;
|
2013-06-11 21:56:55 +00:00
|
|
|
*offset_ptr += src_pos - src;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2011-08-15 02:24:40 +00:00
|
|
|
return bytes_consumed;
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
// Dumps bytes from this object's data to the stream "s" starting
|
2018-04-30 16:49:04 +00:00
|
|
|
// "start_offset" bytes into this data, and ending with the byte before
|
|
|
|
|
// "end_offset". "base_addr" will be added to the offset into the dumped data
|
|
|
|
|
// when showing the offset into the data in the output information.
|
|
|
|
|
// "num_per_line" objects of type "type" will be dumped with the option to
|
|
|
|
|
// override the format for each object with "type_format". "type_format" is a
|
|
|
|
|
// printf style formatting string. If "type_format" is nullptr, then an
|
|
|
|
|
// appropriate format string will be used for the supplied "type". If the
|
|
|
|
|
// stream "s" is nullptr, then the output will be send to Log().
|
2016-03-02 02:18:18 +00:00
|
|
|
lldb::offset_t DataExtractor::PutToLog(Log *log, offset_t start_offset,
|
|
|
|
|
offset_t length, uint64_t base_addr,
|
|
|
|
|
uint32_t num_per_line,
|
|
|
|
|
DataExtractor::Type type,
|
|
|
|
|
const char *format) const {
|
|
|
|
|
if (log == nullptr)
|
2010-06-08 16:52:24 +00:00
|
|
|
return start_offset;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-01-25 18:06:21 +00:00
|
|
|
offset_t offset;
|
|
|
|
|
offset_t end_offset;
|
2010-06-08 16:52:24 +00:00
|
|
|
uint32_t count;
|
|
|
|
|
StreamString sstr;
|
2010-07-09 23:04:08 +00:00
|
|
|
for (offset = start_offset, end_offset = offset + length, count = 0;
|
|
|
|
|
ValidOffset(offset) && offset < end_offset; ++count) {
|
2010-06-08 16:52:24 +00:00
|
|
|
if ((count % num_per_line) == 0) {
|
|
|
|
|
// Print out any previous string
|
|
|
|
|
if (sstr.GetSize() > 0) {
|
2016-11-16 21:15:24 +00:00
|
|
|
log->PutString(sstr.GetString());
|
2010-06-08 16:52:24 +00:00
|
|
|
sstr.Clear();
|
|
|
|
|
}
|
|
|
|
|
// Reset string offset and fill the current line string with address:
|
|
|
|
|
if (base_addr != LLDB_INVALID_ADDRESS)
|
2012-11-29 21:49:15 +00:00
|
|
|
sstr.Printf("0x%8.8" PRIx64 ":",
|
2019-05-23 05:12:11 +00:00
|
|
|
static_cast<uint64_t>(base_addr + (offset - start_offset)));
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
switch (type) {
|
|
|
|
|
case TypeUInt8:
|
|
|
|
|
sstr.Printf(format ? format : " %2.2x", GetU8(&offset));
|
|
|
|
|
break;
|
|
|
|
|
case TypeChar: {
|
|
|
|
|
char ch = GetU8(&offset);
|
|
|
|
|
sstr.Printf(format ? format : " %c", isprint(ch) ? ch : ' ');
|
|
|
|
|
} break;
|
|
|
|
|
case TypeUInt16:
|
|
|
|
|
sstr.Printf(format ? format : " %4.4x", GetU16(&offset));
|
|
|
|
|
break;
|
|
|
|
|
case TypeUInt32:
|
|
|
|
|
sstr.Printf(format ? format : " %8.8x", GetU32(&offset));
|
|
|
|
|
break;
|
2012-11-29 21:49:15 +00:00
|
|
|
case TypeUInt64:
|
|
|
|
|
sstr.Printf(format ? format : " %16.16" PRIx64, GetU64(&offset));
|
|
|
|
|
break;
|
|
|
|
|
case TypePointer:
|
|
|
|
|
sstr.Printf(format ? format : " 0x%" PRIx64, GetAddress(&offset));
|
|
|
|
|
break;
|
|
|
|
|
case TypeULEB128:
|
|
|
|
|
sstr.Printf(format ? format : " 0x%" PRIx64, GetULEB128(&offset));
|
|
|
|
|
break;
|
|
|
|
|
case TypeSLEB128:
|
|
|
|
|
sstr.Printf(format ? format : " %" PRId64, GetSLEB128(&offset));
|
|
|
|
|
break;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
|
2016-11-16 21:15:24 +00:00
|
|
|
if (!sstr.Empty())
|
|
|
|
|
log->PutString(sstr.GetString());
|
2010-06-08 16:52:24 +00:00
|
|
|
|
|
|
|
|
return offset; // Return the offset at which we ended up
|
|
|
|
|
}
|
|
|
|
|
|
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-06 19:20:51 +00:00
|
|
|
size_t DataExtractor::Copy(DataExtractor &dest_data) const {
|
2016-03-02 02:18:18 +00:00
|
|
|
if (m_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-06 19:20:51 +00:00
|
|
|
// we can pass along the SP to the data
|
|
|
|
|
dest_data.SetData(m_data_sp);
|
|
|
|
|
} else {
|
|
|
|
|
const uint8_t *base_ptr = m_start;
|
|
|
|
|
size_t data_size = GetByteSize();
|
|
|
|
|
dest_data.SetData(DataBufferSP(new DataBufferHeap(base_ptr, data_size)));
|
|
|
|
|
}
|
|
|
|
|
return GetByteSize();
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00: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-06 19:20:51 +00:00
|
|
|
bool DataExtractor::Append(DataExtractor &rhs) {
|
|
|
|
|
if (rhs.GetByteOrder() != GetByteOrder())
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
if (rhs.GetByteSize() == 0)
|
|
|
|
|
return true;
|
2016-09-06 20:57:50 +00: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-06 19:20:51 +00:00
|
|
|
if (GetByteSize() == 0)
|
|
|
|
|
return (rhs.Copy(*this) > 0);
|
2016-09-06 20:57:50 +00: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-06 19:20:51 +00:00
|
|
|
size_t bytes = GetByteSize() + rhs.GetByteSize();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2016-03-02 02:18:18 +00:00
|
|
|
DataBufferHeap *buffer_heap_ptr = nullptr;
|
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-06 19:20:51 +00:00
|
|
|
DataBufferSP buffer_sp(buffer_heap_ptr = new DataBufferHeap(bytes, 0));
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2016-03-02 02:18:18 +00:00
|
|
|
if (!buffer_sp || buffer_heap_ptr == nullptr)
|
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-06 19:20:51 +00:00
|
|
|
return false;
|
2016-09-06 20:57:50 +00: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-06 19:20:51 +00:00
|
|
|
uint8_t *bytes_ptr = buffer_heap_ptr->GetBytes();
|
2016-09-06 20:57:50 +00: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-06 19:20:51 +00:00
|
|
|
memcpy(bytes_ptr, GetDataStart(), GetByteSize());
|
|
|
|
|
memcpy(bytes_ptr + GetByteSize(), rhs.GetDataStart(), rhs.GetByteSize());
|
2016-09-06 20:57:50 +00: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-06 19:20:51 +00:00
|
|
|
SetData(buffer_sp);
|
2016-09-06 20:57:50 +00: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-06 19:20:51 +00:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2013-01-25 18:06:21 +00:00
|
|
|
bool DataExtractor::Append(void *buf, offset_t length) {
|
2016-03-02 02:18:18 +00:00
|
|
|
if (buf == nullptr)
|
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-06 19:20:51 +00:00
|
|
|
return false;
|
2016-09-06 20:57:50 +00: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-06 19:20:51 +00:00
|
|
|
if (length == 0)
|
|
|
|
|
return true;
|
2016-09-06 20:57:50 +00: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-06 19:20:51 +00:00
|
|
|
size_t bytes = GetByteSize() + length;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2016-03-02 02:18:18 +00:00
|
|
|
DataBufferHeap *buffer_heap_ptr = nullptr;
|
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-06 19:20:51 +00:00
|
|
|
DataBufferSP buffer_sp(buffer_heap_ptr = new DataBufferHeap(bytes, 0));
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2016-03-02 02:18:18 +00:00
|
|
|
if (!buffer_sp || buffer_heap_ptr == nullptr)
|
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-06 19:20:51 +00:00
|
|
|
return false;
|
2016-09-06 20:57:50 +00: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-06 19:20:51 +00:00
|
|
|
uint8_t *bytes_ptr = buffer_heap_ptr->GetBytes();
|
2016-09-06 20:57:50 +00: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-06 19:20:51 +00:00
|
|
|
if (GetByteSize() > 0)
|
|
|
|
|
memcpy(bytes_ptr, GetDataStart(), GetByteSize());
|
2016-09-06 20:57:50 +00: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-06 19:20:51 +00:00
|
|
|
memcpy(bytes_ptr + GetByteSize(), buf, length);
|
2016-09-06 20:57:50 +00: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-06 19:20:51 +00:00
|
|
|
SetData(buffer_sp);
|
2016-09-06 20:57:50 +00: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-06 19:20:51 +00:00
|
|
|
return true;
|
2011-10-12 00:53:29 +00:00
|
|
|
}
|
2014-12-09 21:18:59 +00:00
|
|
|
|
|
|
|
|
void DataExtractor::Checksum(llvm::SmallVectorImpl<uint8_t> &dest,
|
|
|
|
|
uint64_t max_data) {
|
|
|
|
|
if (max_data == 0)
|
|
|
|
|
max_data = GetByteSize();
|
|
|
|
|
else
|
|
|
|
|
max_data = std::min(max_data, GetByteSize());
|
|
|
|
|
|
|
|
|
|
llvm::MD5 md5;
|
|
|
|
|
|
|
|
|
|
const llvm::ArrayRef<uint8_t> data(GetDataStart(), max_data);
|
|
|
|
|
md5.update(data);
|
|
|
|
|
|
|
|
|
|
llvm::MD5::MD5Result result;
|
|
|
|
|
md5.final(result);
|
|
|
|
|
|
2017-03-20 23:33:18 +00:00
|
|
|
dest.clear();
|
|
|
|
|
dest.append(result.Bytes.begin(), result.Bytes.end());
|
2014-12-09 21:18:59 +00:00
|
|
|
}
|