[lldb][NFC] Fix all formatting errors in .cpp file headers
Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).
This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).
Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73258
2020-01-24 08:23:27 +01:00
|
|
|
//===-- SBValue.cpp -------------------------------------------------------===//
|
2010-06-08 16:52:24 +00:00
|
|
|
//
|
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
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2010-06-09 07:44:37 +00:00
|
|
|
#include "lldb/API/SBValue.h"
|
2022-01-19 11:38:26 -08:00
|
|
|
#include "lldb/Utility/Instrumentation.h"
|
2012-02-17 03:18:30 +00:00
|
|
|
|
2012-10-10 22:54:17 +00:00
|
|
|
#include "lldb/API/SBDeclaration.h"
|
2010-09-20 05:20:02 +00:00
|
|
|
#include "lldb/API/SBStream.h"
|
2012-02-17 03:18:30 +00:00
|
|
|
#include "lldb/API/SBTypeFilter.h"
|
|
|
|
#include "lldb/API/SBTypeFormat.h"
|
|
|
|
#include "lldb/API/SBTypeSummary.h"
|
|
|
|
#include "lldb/API/SBTypeSynthetic.h"
|
2010-06-08 16:52:24 +00:00
|
|
|
|
2011-10-14 00:42:25 +00:00
|
|
|
#include "lldb/Breakpoint/Watchpoint.h"
|
2021-04-30 03:35:59 +00:00
|
|
|
#include "lldb/Core/Declaration.h"
|
2010-06-08 16:52:24 +00:00
|
|
|
#include "lldb/Core/Module.h"
|
<rdar://problem/11757916>
Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file".
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()
Cleaned up header includes a bit as well.
llvm-svn: 162860
2012-08-29 21:13:06 +00:00
|
|
|
#include "lldb/Core/Section.h"
|
2010-06-08 16:52:24 +00:00
|
|
|
#include "lldb/Core/Value.h"
|
|
|
|
#include "lldb/Core/ValueObject.h"
|
2011-07-29 19:53:35 +00:00
|
|
|
#include "lldb/Core/ValueObjectConstResult.h"
|
2013-01-28 23:47:25 +00:00
|
|
|
#include "lldb/DataFormatters/DataVisualization.h"
|
2023-12-18 21:23:03 +01:00
|
|
|
#include "lldb/DataFormatters/DumpValueObjectOptions.h"
|
2010-06-08 16:52:24 +00:00
|
|
|
#include "lldb/Symbol/Block.h"
|
|
|
|
#include "lldb/Symbol/ObjectFile.h"
|
2012-02-04 02:27:34 +00:00
|
|
|
#include "lldb/Symbol/Type.h"
|
2010-06-08 16:52:24 +00:00
|
|
|
#include "lldb/Symbol/Variable.h"
|
2011-10-14 00:42:25 +00:00
|
|
|
#include "lldb/Symbol/VariableList.h"
|
2010-06-08 16:52:24 +00:00
|
|
|
#include "lldb/Target/ExecutionContext.h"
|
|
|
|
#include "lldb/Target/Process.h"
|
2013-11-04 09:33:30 +00:00
|
|
|
#include "lldb/Target/StackFrame.h"
|
2010-12-20 20:49:23 +00:00
|
|
|
#include "lldb/Target/Target.h"
|
2010-06-08 16:52:24 +00:00
|
|
|
#include "lldb/Target/Thread.h"
|
2017-03-04 01:30:05 +00:00
|
|
|
#include "lldb/Utility/DataExtractor.h"
|
2018-08-07 11:07:21 +00:00
|
|
|
#include "lldb/Utility/Scalar.h"
|
2017-02-02 21:39:50 +00:00
|
|
|
#include "lldb/Utility/Stream.h"
|
2010-06-08 16:52:24 +00:00
|
|
|
|
2012-10-16 21:41:58 +00:00
|
|
|
#include "lldb/API/SBDebugger.h"
|
|
|
|
#include "lldb/API/SBExpressionOptions.h"
|
|
|
|
#include "lldb/API/SBFrame.h"
|
2010-06-09 07:44:37 +00:00
|
|
|
#include "lldb/API/SBProcess.h"
|
|
|
|
#include "lldb/API/SBTarget.h"
|
|
|
|
#include "lldb/API/SBThread.h"
|
2010-06-08 16:52:24 +00:00
|
|
|
|
2019-02-11 23:13:08 +00:00
|
|
|
#include <memory>
|
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
using namespace lldb;
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
2013-04-22 22:57:56 +00:00
|
|
|
class ValueImpl {
|
|
|
|
public:
|
2020-02-17 22:57:06 -08:00
|
|
|
ValueImpl() = default;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueImpl(lldb::ValueObjectSP in_valobj_sp,
|
2013-04-22 22:57:56 +00:00
|
|
|
lldb::DynamicValueType use_dynamic, bool use_synthetic,
|
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
2019-05-23 11:14:47 +00:00
|
|
|
const char *name = nullptr)
|
2022-01-02 22:44:15 -08:00
|
|
|
: m_use_dynamic(use_dynamic), m_use_synthetic(use_synthetic),
|
|
|
|
m_name(name) {
|
2015-06-24 19:53:22 +00:00
|
|
|
if (in_valobj_sp) {
|
|
|
|
if ((m_valobj_sp = in_valobj_sp->GetQualifiedRepresentationIfAvailable(
|
|
|
|
lldb::eNoDynamicValues, false))) {
|
|
|
|
if (!m_name.IsEmpty())
|
|
|
|
m_valobj_sp->SetName(m_name);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2013-04-22 22:57:56 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2022-03-31 13:20:46 -07:00
|
|
|
ValueImpl(const ValueImpl &rhs) = default;
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2013-04-22 22:57:56 +00:00
|
|
|
ValueImpl &operator=(const ValueImpl &rhs) {
|
|
|
|
if (this != &rhs) {
|
2013-08-26 23:57:52 +00:00
|
|
|
m_valobj_sp = rhs.m_valobj_sp;
|
|
|
|
m_use_dynamic = rhs.m_use_dynamic;
|
|
|
|
m_use_synthetic = rhs.m_use_synthetic;
|
|
|
|
m_name = rhs.m_name;
|
2013-04-22 22:57:56 +00:00
|
|
|
}
|
2010-11-05 23:17:00 +00:00
|
|
|
return *this;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2013-04-22 22:57:56 +00:00
|
|
|
bool IsValid() {
|
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
2019-05-23 11:14:47 +00:00
|
|
|
if (m_valobj_sp.get() == nullptr)
|
2013-12-06 22:21:04 +00:00
|
|
|
return false;
|
2016-09-06 20:57:50 +00:00
|
|
|
else {
|
2013-12-06 22:21:04 +00:00
|
|
|
// FIXME: This check is necessary but not sufficient. We for sure don't
|
|
|
|
// want to touch SBValues whose owning
|
|
|
|
// targets have gone away. This check is a little weak in that it
|
2018-04-30 16:49:04 +00:00
|
|
|
// enforces that restriction when you call IsValid, but since IsValid
|
|
|
|
// doesn't lock the target, you have no guarantee that the SBValue won't
|
|
|
|
// go invalid after you call this... Also, an SBValue could depend on
|
|
|
|
// data from one of the modules in the target, and those could go away
|
|
|
|
// independently of the target, for instance if a module is unloaded.
|
|
|
|
// But right now, neither SBValues nor ValueObjects know which modules
|
|
|
|
// they depend on. So I have no good way to make that check without
|
2013-05-15 02:16:21 +00:00
|
|
|
// tracking that in all the ValueObject subclasses.
|
|
|
|
TargetSP target_sp = m_valobj_sp->GetTargetSP();
|
2018-12-15 00:15:33 +00:00
|
|
|
return target_sp && target_sp->IsValid();
|
2013-04-22 22:57:56 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2013-12-06 22:21:04 +00:00
|
|
|
lldb::ValueObjectSP GetRootSP() { return m_valobj_sp; }
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2013-04-22 22:57:56 +00:00
|
|
|
lldb::ValueObjectSP GetSP(Process::StopLocker &stop_locker,
|
2016-05-19 05:13:57 +00:00
|
|
|
std::unique_lock<std::recursive_mutex> &lock,
|
2017-05-12 04:51:55 +00:00
|
|
|
Status &error) {
|
2013-04-22 22:57:56 +00:00
|
|
|
if (!m_valobj_sp) {
|
|
|
|
error.SetErrorString("invalid value object");
|
2013-05-15 02:16:21 +00:00
|
|
|
return m_valobj_sp;
|
2013-04-22 22:57:56 +00:00
|
|
|
}
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
lldb::ValueObjectSP value_sp = m_valobj_sp;
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2013-04-22 22:57:56 +00:00
|
|
|
Target *target = value_sp->GetTargetSP().get();
|
2023-02-28 16:38:50 -08:00
|
|
|
// If this ValueObject holds an error, then it is valuable for that.
|
2023-10-30 17:46:18 -07:00
|
|
|
if (value_sp->GetError().Fail())
|
2023-02-28 16:38:50 -08:00
|
|
|
return value_sp;
|
|
|
|
|
2016-05-19 05:13:57 +00:00
|
|
|
if (!target)
|
2013-12-06 22:21:04 +00:00
|
|
|
return ValueObjectSP();
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2016-05-19 05:13:57 +00:00
|
|
|
lock = std::unique_lock<std::recursive_mutex>(target->GetAPIMutex());
|
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
ProcessSP process_sp(value_sp->GetProcessSP());
|
|
|
|
if (process_sp && !stop_locker.TryLock(&process_sp->GetRunLock())) {
|
2018-04-30 16:49:04 +00:00
|
|
|
// We don't allow people to play around with ValueObject if the process
|
|
|
|
// is running. If you want to look at values, pause the process, then
|
|
|
|
// look.
|
2013-05-15 02:16:21 +00:00
|
|
|
error.SetErrorString("process must be stopped.");
|
|
|
|
return ValueObjectSP();
|
|
|
|
}
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2015-06-22 17:38:30 +00:00
|
|
|
if (m_use_dynamic != eNoDynamicValues) {
|
|
|
|
ValueObjectSP dynamic_sp = value_sp->GetDynamicValue(m_use_dynamic);
|
|
|
|
if (dynamic_sp)
|
|
|
|
value_sp = dynamic_sp;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (m_use_synthetic) {
|
2020-05-08 19:09:30 +02:00
|
|
|
ValueObjectSP synthetic_sp = value_sp->GetSyntheticValue();
|
2015-06-22 17:38:30 +00:00
|
|
|
if (synthetic_sp)
|
|
|
|
value_sp = synthetic_sp;
|
|
|
|
}
|
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
if (!value_sp)
|
|
|
|
error.SetErrorString("invalid value object");
|
|
|
|
if (!m_name.IsEmpty())
|
|
|
|
value_sp->SetName(m_name);
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2013-04-22 22:57:56 +00:00
|
|
|
return value_sp;
|
|
|
|
}
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2013-04-22 22:57:56 +00:00
|
|
|
void SetUseDynamic(lldb::DynamicValueType use_dynamic) {
|
|
|
|
m_use_dynamic = use_dynamic;
|
|
|
|
}
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2013-04-22 22:57:56 +00:00
|
|
|
void SetUseSynthetic(bool use_synthetic) { m_use_synthetic = use_synthetic; }
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2013-04-22 22:57:56 +00:00
|
|
|
lldb::DynamicValueType GetUseDynamic() { return m_use_dynamic; }
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2013-04-22 22:57:56 +00:00
|
|
|
bool GetUseSynthetic() { return m_use_synthetic; }
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
// All the derived values that we would make from the m_valobj_sp will share
|
|
|
|
// the ExecutionContext with m_valobj_sp, so we don't need to do the
|
2018-04-30 16:49:04 +00:00
|
|
|
// calculations in GetSP to return the Target, Process, Thread or Frame. It
|
|
|
|
// is convenient to provide simple accessors for these, which I do here.
|
2013-05-15 02:16:21 +00:00
|
|
|
TargetSP GetTargetSP() {
|
|
|
|
if (m_valobj_sp)
|
|
|
|
return m_valobj_sp->GetTargetSP();
|
|
|
|
else
|
|
|
|
return TargetSP();
|
|
|
|
}
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
ProcessSP GetProcessSP() {
|
|
|
|
if (m_valobj_sp)
|
|
|
|
return m_valobj_sp->GetProcessSP();
|
|
|
|
else
|
|
|
|
return ProcessSP();
|
|
|
|
}
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
ThreadSP GetThreadSP() {
|
|
|
|
if (m_valobj_sp)
|
|
|
|
return m_valobj_sp->GetThreadSP();
|
|
|
|
else
|
|
|
|
return ThreadSP();
|
|
|
|
}
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2013-11-04 09:33:30 +00:00
|
|
|
StackFrameSP GetFrameSP() {
|
2013-05-15 02:16:21 +00:00
|
|
|
if (m_valobj_sp)
|
|
|
|
return m_valobj_sp->GetFrameSP();
|
|
|
|
else
|
2013-11-04 09:33:30 +00:00
|
|
|
return StackFrameSP();
|
2013-05-15 02:16:21 +00:00
|
|
|
}
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2013-04-22 22:57:56 +00:00
|
|
|
private:
|
2013-05-15 02:16:21 +00:00
|
|
|
lldb::ValueObjectSP m_valobj_sp;
|
2013-04-22 22:57:56 +00:00
|
|
|
lldb::DynamicValueType m_use_dynamic;
|
|
|
|
bool m_use_synthetic;
|
2013-05-15 02:16:21 +00:00
|
|
|
ConstString m_name;
|
|
|
|
};
|
|
|
|
|
|
|
|
class ValueLocker {
|
|
|
|
public:
|
2020-02-17 22:57:06 -08:00
|
|
|
ValueLocker() = default;
|
2016-05-19 05:13:57 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueObjectSP GetLockedSP(ValueImpl &in_value) {
|
2016-05-19 05:13:57 +00:00
|
|
|
return in_value.GetSP(m_stop_locker, m_lock, m_lock_error);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2017-05-12 04:51:55 +00:00
|
|
|
Status &GetError() { return m_lock_error; }
|
2016-05-19 05:13:57 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
private:
|
|
|
|
Process::StopLocker m_stop_locker;
|
2016-05-19 05:13:57 +00:00
|
|
|
std::unique_lock<std::recursive_mutex> m_lock;
|
2017-05-12 04:51:55 +00:00
|
|
|
Status m_lock_error;
|
2013-04-22 22:57:56 +00:00
|
|
|
};
|
2012-10-22 18:18:36 +00:00
|
|
|
|
2022-01-19 11:38:26 -08:00
|
|
|
SBValue::SBValue() { LLDB_INSTRUMENT_VA(this); }
|
2010-06-08 16:52:24 +00:00
|
|
|
|
2019-03-06 00:06:00 +00:00
|
|
|
SBValue::SBValue(const lldb::ValueObjectSP &value_sp) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, value_sp);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-03-06 00:06:00 +00:00
|
|
|
SetSP(value_sp);
|
|
|
|
}
|
|
|
|
|
|
|
|
SBValue::SBValue(const SBValue &rhs) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, rhs);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
|
|
|
SetSP(rhs.m_opaque_sp);
|
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
|
2012-03-27 02:35:13 +00:00
|
|
|
SBValue &SBValue::operator=(const SBValue &rhs) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, rhs);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2010-11-05 23:17:00 +00:00
|
|
|
if (this != &rhs) {
|
2012-10-22 18:18:36 +00:00
|
|
|
SetSP(rhs.m_opaque_sp);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2022-01-09 22:54:08 -08:00
|
|
|
return *this;
|
2010-11-05 23:17:00 +00:00
|
|
|
}
|
|
|
|
|
2020-02-17 22:57:06 -08:00
|
|
|
SBValue::~SBValue() = default;
|
2010-11-05 23:17:00 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
bool SBValue::IsValid() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
Add "operator bool" to SB APIs
Summary:
Our python version of the SB API has (the python equivalent of)
operator bool, but the C++ version doesn't.
This is because our python operators are added by modify-python-lldb.py,
which performs postprocessing on the swig-generated interface files.
In this patch, I add the "operator bool" to all SB classes which have an
IsValid method (which is the same logic used by modify-python-lldb.py).
This way, we make the two interfaces more constent, and it allows us to
rely on swig's automatic syntesis of python __nonzero__ methods instead
of doing manual fixups.
Reviewers: zturner, jingham, clayborg, jfb, serge-sans-paille
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D58792
llvm-svn: 355824
2019-03-11 13:58:46 +00:00
|
|
|
return this->operator bool();
|
|
|
|
}
|
|
|
|
SBValue::operator bool() const {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// If this function ever changes to anything that does more than just check
|
|
|
|
// if the opaque shared pointer is non NULL, then we need to update all "if
|
|
|
|
// (m_opaque_sp)" code in this file.
|
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
2019-05-23 11:14:47 +00:00
|
|
|
return m_opaque_sp.get() != nullptr && m_opaque_sp->IsValid() &&
|
|
|
|
m_opaque_sp->GetRootSP().get() != nullptr;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
2019-03-06 00:06:00 +00:00
|
|
|
void SBValue::Clear() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
|
|
|
m_opaque_sp.reset();
|
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
|
2011-12-19 20:39:44 +00:00
|
|
|
SBError SBValue::GetError() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2011-12-19 20:39:44 +00:00
|
|
|
SBError sb_error;
|
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-04 02:27:34 +00:00
|
|
|
if (value_sp)
|
|
|
|
sb_error.SetError(value_sp->GetError());
|
2016-09-06 20:57:50 +00:00
|
|
|
else
|
2010-06-08 16:52:24 +00:00
|
|
|
sb_error.SetErrorStringWithFormat("error: %s",
|
2012-02-04 02:27:34 +00:00
|
|
|
locker.GetError().AsCString());
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2022-01-09 22:54:08 -08:00
|
|
|
return sb_error;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
user_id_t SBValue::GetID() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
Introduce the concept of a "display name" for types
Rationale:
Pretty simply, the idea is that sometimes type names are way too long and contain way too many details for the average developer to care about. For instance, a plain ol' vector of int might be shown as
std::__1::vector<int, std::__1::allocator<....
rather than the much simpler std::vector<int> form, which is what most developers would actually type in their code
Proposed solution:
Introduce a notion of "display name" and a corresponding API GetDisplayTypeName() to return such a crafted for visual representation type name
Obviously, the display name and the fully qualified (or "true") name are not necessarily the same - that's the whole point
LLDB could choose to pick the "display name" as its one true notion of a type name, and if somebody really needs the fully qualified version of it, let them deal with the problem
Or, LLDB could rename what it currently calls the "type name" to be the "display name", and add new APIs for the fully qualified name, making the display name the default choice
The choice that I am making here is that the type name will keep meaning the same, and people who want a type name suited for display will explicitly ask for one
It is the less risky/disruptive choice - and it should eventually make it fairly obvious when someone is asking for the wrong type
Caveats:
- for now, GetDisplayTypeName() == GetTypeName(), there is no logic to produce customized display type names yet.
- while the fully-qualified type name is still the main key to the kingdom of data formatters, if we start showing custom names to people, those should match formatters
llvm-svn: 209072
2014-05-17 19:14:17 +00:00
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
|
|
|
if (value_sp)
|
|
|
|
return value_sp->GetID();
|
|
|
|
return LLDB_INVALID_UID;
|
|
|
|
}
|
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
const char *SBValue::GetName() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2023-05-17 10:44:38 -07:00
|
|
|
if (!value_sp)
|
|
|
|
return nullptr;
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2023-05-17 10:44:38 -07:00
|
|
|
return value_sp->GetName().GetCString();
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2011-05-04 03:43:18 +00:00
|
|
|
const char *SBValue::GetTypeName() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2023-05-17 10:44:38 -07:00
|
|
|
if (!value_sp)
|
|
|
|
return nullptr;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2023-05-17 10:44:38 -07:00
|
|
|
return value_sp->GetQualifiedTypeName().GetCString();
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2011-05-04 03:43:18 +00:00
|
|
|
const char *SBValue::GetDisplayTypeName() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2023-05-17 10:44:38 -07:00
|
|
|
if (!value_sp)
|
|
|
|
return nullptr;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2023-05-17 10:44:38 -07:00
|
|
|
return value_sp->GetDisplayTypeName().GetCString();
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
2011-03-31 00:19:25 +00:00
|
|
|
size_t SBValue::GetByteSize() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
size_t result = 0;
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-04 02:27:34 +00:00
|
|
|
if (value_sp) {
|
2022-06-19 09:12:01 -07:00
|
|
|
result = value_sp->GetByteSize().value_or(0);
|
2010-12-20 20:49:23 +00:00
|
|
|
}
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2011-03-31 00:19:25 +00:00
|
|
|
bool SBValue::IsInScope() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2013-03-27 23:08:40 +00:00
|
|
|
bool result = false;
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-04 02:27:34 +00:00
|
|
|
if (value_sp) {
|
2013-05-15 02:16:21 +00:00
|
|
|
result = value_sp->IsInScope();
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2010-10-31 03:01:06 +00:00
|
|
|
return result;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
2010-10-27 03:32:59 +00:00
|
|
|
const char *SBValue::GetValue() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2013-03-27 23:08:40 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2023-05-17 10:44:38 -07:00
|
|
|
if (!value_sp)
|
|
|
|
return nullptr;
|
|
|
|
return ConstString(value_sp->GetValueAsCString()).GetCString();
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2014-04-04 04:06:10 +00:00
|
|
|
ValueType SBValue::GetValueType() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2014-04-04 04:06:10 +00:00
|
|
|
ValueType result = eValueTypeInvalid;
|
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
|
|
|
if (value_sp)
|
|
|
|
result = value_sp->GetValueType();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2014-09-06 01:30:04 +00:00
|
|
|
return result;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2014-09-06 01:30:04 +00:00
|
|
|
const char *SBValue::GetObjectDescription() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2014-09-06 01:30:04 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2023-05-17 10:44:38 -07:00
|
|
|
if (!value_sp)
|
|
|
|
return nullptr;
|
2019-03-07 22:47:13 +00:00
|
|
|
|
2024-06-17 17:07:36 -07:00
|
|
|
llvm::Expected<std::string> str = value_sp->GetObjectDescription();
|
|
|
|
if (!str)
|
|
|
|
return ConstString("error: " + toString(str.takeError())).AsCString();
|
|
|
|
return ConstString(*str).AsCString();
|
2010-09-10 23:12:17 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-03-31 00:19:25 +00:00
|
|
|
SBType SBValue::GetType() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2012-02-04 02:27:34 +00:00
|
|
|
SBType sb_type;
|
2011-03-31 00:19:25 +00:00
|
|
|
ValueLocker locker;
|
2013-03-27 23:08:40 +00:00
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2013-05-15 02:16:21 +00:00
|
|
|
TypeImplSP type_sp;
|
2012-02-04 02:27:34 +00:00
|
|
|
if (value_sp) {
|
2019-02-11 23:13:08 +00:00
|
|
|
type_sp = std::make_shared<TypeImpl>(value_sp->GetTypeImpl());
|
2015-08-11 22:53:00 +00:00
|
|
|
sb_type.SetSP(type_sp);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2019-03-07 22:47:13 +00:00
|
|
|
|
2022-01-09 22:54:08 -08:00
|
|
|
return sb_type;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-03-31 00:19:25 +00:00
|
|
|
bool SBValue::GetValueDidChange() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2010-10-31 03:01:06 +00:00
|
|
|
bool result = false;
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-04 02:27:34 +00:00
|
|
|
if (value_sp) {
|
|
|
|
if (value_sp->UpdateValueIfNeeded(false))
|
2015-02-06 18:10:30 +00:00
|
|
|
result = value_sp->GetValueDidChange();
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2010-10-31 03:01:06 +00:00
|
|
|
return result;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2010-12-20 20:49:23 +00:00
|
|
|
const char *SBValue::GetSummary() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2023-05-17 10:44:38 -07:00
|
|
|
if (!value_sp)
|
|
|
|
return nullptr;
|
2019-03-07 22:47:13 +00:00
|
|
|
|
2023-05-17 10:44:38 -07:00
|
|
|
return ConstString(value_sp->GetSummaryAsCString()).GetCString();
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2014-11-18 23:36:25 +00:00
|
|
|
const char *SBValue::GetSummary(lldb::SBStream &stream,
|
|
|
|
lldb::SBTypeSummaryOptions &options) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, stream, options);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2014-11-06 21:23:20 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
|
|
|
if (value_sp) {
|
2014-11-18 23:36:25 +00:00
|
|
|
std::string buffer;
|
|
|
|
if (value_sp->GetSummaryAsCString(buffer, options.ref()) && !buffer.empty())
|
|
|
|
stream.Printf("%s", buffer.c_str());
|
2014-11-06 21:23:20 +00:00
|
|
|
}
|
2023-05-17 10:44:38 -07:00
|
|
|
return ConstString(stream.GetData()).GetCString();
|
2014-11-06 21:23:20 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-03-31 00:19:25 +00:00
|
|
|
const char *SBValue::GetLocation() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2023-05-17 10:44:38 -07:00
|
|
|
if (!value_sp)
|
|
|
|
return nullptr;
|
|
|
|
|
|
|
|
return ConstString(value_sp->GetLocationAsCString()).GetCString();
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
2012-05-08 21:25:06 +00:00
|
|
|
// Deprecated - use the one that takes an lldb::SBError
|
2011-03-31 00:19:25 +00:00
|
|
|
bool SBValue::SetValueFromCString(const char *value_str) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, value_str);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2012-05-08 21:25:06 +00:00
|
|
|
lldb::SBError dummy;
|
|
|
|
return SetValueFromCString(value_str, dummy);
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-05-08 21:25:06 +00:00
|
|
|
bool SBValue::SetValueFromCString(const char *value_str, lldb::SBError &error) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, value_str, error);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
bool success = false;
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-04 02:27:34 +00:00
|
|
|
if (value_sp) {
|
2013-05-15 02:16:21 +00:00
|
|
|
success = value_sp->SetValueFromCString(value_str, error.ref());
|
|
|
|
} else
|
|
|
|
error.SetErrorStringWithFormat("Could not get value: %s",
|
|
|
|
locker.GetError().AsCString());
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
return success;
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-02-17 03:18:30 +00:00
|
|
|
lldb::SBTypeFormat SBValue::GetTypeFormat() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2012-02-17 03:18:30 +00:00
|
|
|
lldb::SBTypeFormat format;
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-17 03:18:30 +00:00
|
|
|
if (value_sp) {
|
2013-05-15 02:16:21 +00:00
|
|
|
if (value_sp->UpdateValueIfNeeded(true)) {
|
|
|
|
lldb::TypeFormatImplSP format_sp = value_sp->GetValueFormat();
|
|
|
|
if (format_sp)
|
|
|
|
format.SetSP(format_sp);
|
2012-02-17 03:18:30 +00:00
|
|
|
}
|
|
|
|
}
|
2022-01-09 22:54:08 -08:00
|
|
|
return format;
|
2012-02-17 03:18:30 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-02-17 03:18:30 +00:00
|
|
|
lldb::SBTypeSummary SBValue::GetTypeSummary() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2012-02-17 03:18:30 +00:00
|
|
|
lldb::SBTypeSummary summary;
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-17 03:18:30 +00:00
|
|
|
if (value_sp) {
|
2013-05-15 02:16:21 +00:00
|
|
|
if (value_sp->UpdateValueIfNeeded(true)) {
|
|
|
|
lldb::TypeSummaryImplSP summary_sp = value_sp->GetSummaryFormat();
|
|
|
|
if (summary_sp)
|
|
|
|
summary.SetSP(summary_sp);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2012-02-17 03:18:30 +00:00
|
|
|
}
|
2022-01-09 22:54:08 -08:00
|
|
|
return summary;
|
2012-02-17 03:18:30 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-02-17 03:18:30 +00:00
|
|
|
lldb::SBTypeFilter SBValue::GetTypeFilter() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2012-02-17 03:18:30 +00:00
|
|
|
lldb::SBTypeFilter filter;
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-17 03:18:30 +00:00
|
|
|
if (value_sp) {
|
2013-05-15 02:16:21 +00:00
|
|
|
if (value_sp->UpdateValueIfNeeded(true)) {
|
|
|
|
lldb::SyntheticChildrenSP synthetic_sp = value_sp->GetSyntheticChildren();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
if (synthetic_sp && !synthetic_sp->IsScripted()) {
|
|
|
|
TypeFilterImplSP filter_sp =
|
|
|
|
std::static_pointer_cast<TypeFilterImpl>(synthetic_sp);
|
|
|
|
filter.SetSP(filter_sp);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2012-02-17 03:18:30 +00:00
|
|
|
}
|
|
|
|
}
|
2022-01-09 22:54:08 -08:00
|
|
|
return filter;
|
2012-02-17 03:18:30 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
lldb::SBTypeSynthetic SBValue::GetTypeSynthetic() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2012-02-17 03:18:30 +00:00
|
|
|
lldb::SBTypeSynthetic synthetic;
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-17 03:18:30 +00:00
|
|
|
if (value_sp) {
|
2013-05-15 02:16:21 +00:00
|
|
|
if (value_sp->UpdateValueIfNeeded(true)) {
|
|
|
|
lldb::SyntheticChildrenSP children_sp = value_sp->GetSyntheticChildren();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
if (children_sp && children_sp->IsScripted()) {
|
|
|
|
ScriptedSyntheticChildrenSP synth_sp =
|
|
|
|
std::static_pointer_cast<ScriptedSyntheticChildren>(children_sp);
|
|
|
|
synthetic.SetSP(synth_sp);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2012-02-17 03:18:30 +00:00
|
|
|
}
|
|
|
|
}
|
2022-01-09 22:54:08 -08:00
|
|
|
return synthetic;
|
2012-02-17 03:18:30 +00:00
|
|
|
}
|
|
|
|
|
2011-09-09 23:04:00 +00:00
|
|
|
lldb::SBValue SBValue::CreateChildAtOffset(const char *name, uint32_t offset,
|
|
|
|
SBType type) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, name, offset, type);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2012-02-04 02:27:34 +00:00
|
|
|
lldb::SBValue sb_value;
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-04 02:27:34 +00:00
|
|
|
lldb::ValueObjectSP new_value_sp;
|
|
|
|
if (value_sp) {
|
2013-05-15 02:16:21 +00:00
|
|
|
TypeImplSP type_sp(type.GetSP());
|
|
|
|
if (type.IsValid()) {
|
2015-08-11 22:53:00 +00:00
|
|
|
sb_value.SetSP(value_sp->GetSyntheticChildAtOffset(
|
|
|
|
offset, type_sp->GetCompilerType(false), true),
|
|
|
|
GetPreferDynamicValue(), GetPreferSyntheticValue(), name);
|
2011-07-29 19:53:35 +00:00
|
|
|
}
|
|
|
|
}
|
2022-01-09 22:54:08 -08:00
|
|
|
return sb_value;
|
2011-07-29 19:53:35 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-09-09 23:04:00 +00:00
|
|
|
lldb::SBValue SBValue::Cast(SBType type) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, type);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2012-01-31 04:25:15 +00:00
|
|
|
lldb::SBValue sb_value;
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-04 02:27:34 +00:00
|
|
|
TypeImplSP type_sp(type.GetSP());
|
|
|
|
if (value_sp && type_sp)
|
2015-08-11 22:53:00 +00:00
|
|
|
sb_value.SetSP(value_sp->Cast(type_sp->GetCompilerType(false)),
|
|
|
|
GetPreferDynamicValue(), GetPreferSyntheticValue());
|
2022-01-09 22:54:08 -08:00
|
|
|
return sb_value;
|
2011-07-29 19:53:35 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-07-29 19:53:35 +00:00
|
|
|
lldb::SBValue SBValue::CreateValueFromExpression(const char *name,
|
|
|
|
const char *expression) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, name, expression);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2012-10-16 21:41:58 +00:00
|
|
|
SBExpressionOptions options;
|
2012-10-16 22:58:25 +00:00
|
|
|
options.ref().SetKeepInMemory(true);
|
2022-01-09 22:54:08 -08:00
|
|
|
return CreateValueFromExpression(name, expression, options);
|
2012-10-16 21:41:58 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-10-16 21:41:58 +00:00
|
|
|
lldb::SBValue SBValue::CreateValueFromExpression(const char *name,
|
|
|
|
const char *expression,
|
|
|
|
SBExpressionOptions &options) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, name, expression, options);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2012-02-04 02:27:34 +00:00
|
|
|
lldb::SBValue sb_value;
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-04 02:27:34 +00:00
|
|
|
lldb::ValueObjectSP new_value_sp;
|
|
|
|
if (value_sp) {
|
2012-02-17 07:49:44 +00:00
|
|
|
ExecutionContext exe_ctx(value_sp->GetExecutionContextRef());
|
2014-12-17 21:18:43 +00:00
|
|
|
new_value_sp = ValueObject::CreateValueObjectFromExpression(
|
|
|
|
name, expression, exe_ctx, options.ref());
|
|
|
|
if (new_value_sp)
|
|
|
|
new_value_sp->SetName(ConstString(name));
|
2011-07-29 19:53:35 +00:00
|
|
|
}
|
2014-12-17 21:18:43 +00:00
|
|
|
sb_value.SetSP(new_value_sp);
|
2022-01-09 22:54:08 -08:00
|
|
|
return sb_value;
|
2011-07-29 19:53:35 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-02-04 02:27:34 +00:00
|
|
|
lldb::SBValue SBValue::CreateValueFromAddress(const char *name,
|
|
|
|
lldb::addr_t address,
|
|
|
|
SBType sb_type) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, name, address, sb_type);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2012-02-04 02:27:34 +00:00
|
|
|
lldb::SBValue sb_value;
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-04 02:27:34 +00:00
|
|
|
lldb::ValueObjectSP new_value_sp;
|
|
|
|
lldb::TypeImplSP type_impl_sp(sb_type.GetSP());
|
|
|
|
if (value_sp && type_impl_sp) {
|
2015-08-11 22:53:00 +00:00
|
|
|
CompilerType ast_type(type_impl_sp->GetCompilerType(true));
|
2014-12-17 21:18:43 +00:00
|
|
|
ExecutionContext exe_ctx(value_sp->GetExecutionContextRef());
|
|
|
|
new_value_sp = ValueObject::CreateValueObjectFromAddress(name, address,
|
|
|
|
exe_ctx, ast_type);
|
2011-07-29 19:53:35 +00:00
|
|
|
}
|
2014-12-17 21:18:43 +00:00
|
|
|
sb_value.SetSP(new_value_sp);
|
2022-01-09 22:54:08 -08:00
|
|
|
return sb_value;
|
2011-07-29 19:53:35 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2016-05-23 17:11:14 +00:00
|
|
|
lldb::SBValue SBValue::CreateValueFromData(const char *name, SBData data,
|
|
|
|
SBType sb_type) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, name, data, sb_type);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2012-02-04 02:27:34 +00:00
|
|
|
lldb::SBValue sb_value;
|
|
|
|
lldb::ValueObjectSP new_value_sp;
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2016-05-23 17:11:14 +00:00
|
|
|
lldb::TypeImplSP type_impl_sp(sb_type.GetSP());
|
|
|
|
if (value_sp && type_impl_sp) {
|
2012-02-17 07:49:44 +00:00
|
|
|
ExecutionContext exe_ctx(value_sp->GetExecutionContextRef());
|
2016-05-23 17:11:14 +00:00
|
|
|
new_value_sp = ValueObject::CreateValueObjectFromData(
|
|
|
|
name, **data, exe_ctx, type_impl_sp->GetCompilerType(true));
|
2012-02-04 02:27:34 +00:00
|
|
|
new_value_sp->SetAddressTypeOfChildren(eAddressTypeLoad);
|
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
|
|
|
}
|
2014-12-17 21:18:43 +00:00
|
|
|
sb_value.SetSP(new_value_sp);
|
2022-01-09 22:54:08 -08:00
|
|
|
return sb_value;
|
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
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
SBValue SBValue::GetChildAtIndex(uint32_t idx) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, idx);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
Added the ability to get synthetic child values from SBValue objects that
represent pointers and arrays by adding an extra parameter to the
SBValue
SBValue::GetChildAtIndex (uint32_t idx,
DynamicValueType use_dynamic,
bool can_create_synthetic);
The new "can_create_synthetic" will allow you to create child values that
aren't actually a part of the original type. So if you code like:
int *foo_ptr = ...
And you have a SBValue that contains the value for "foo_ptr":
SBValue foo_value = ...
You can now get the "foo_ptr[12]" item by doing this:
v = foo_value.GetChiltAtIndex (12, lldb.eNoDynamicValues, True);
Normall the "foo_value" would only have one child value (an integer), but
we can create "synthetic" child values by treating the pointer as an array.
Likewise if you have code like:
int array[2];
array_value = ....
v = array_value.GetChiltAtIndex (0); // Success, v will be valid
v = array_value.GetChiltAtIndex (1); // Success, v will be valid
v = array_value.GetChiltAtIndex (2); // Fail, v won't be valid, "2" is not a valid zero based index in "array"
But if you use the ability to create synthetic children:
v = array_value.GetChiltAtIndex (0, lldb.eNoDynamicValues, True); // Success, v will be valid
v = array_value.GetChiltAtIndex (1, lldb.eNoDynamicValues, True); // Success, v will be valid
v = array_value.GetChiltAtIndex (2, lldb.eNoDynamicValues, True); // Success, v will be valid
llvm-svn: 135292
2011-07-15 19:31:49 +00:00
|
|
|
const bool can_create_synthetic = false;
|
|
|
|
lldb::DynamicValueType use_dynamic = eNoDynamicValues;
|
2013-05-15 02:16:21 +00:00
|
|
|
TargetSP target_sp;
|
|
|
|
if (m_opaque_sp)
|
|
|
|
target_sp = m_opaque_sp->GetTargetSP();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
if (target_sp)
|
|
|
|
use_dynamic = target_sp->GetPreferDynamicValue();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2022-01-09 22:54:08 -08:00
|
|
|
return GetChildAtIndex(idx, use_dynamic, can_create_synthetic);
|
2011-04-16 00:01:13 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
Added the ability to get synthetic child values from SBValue objects that
represent pointers and arrays by adding an extra parameter to the
SBValue
SBValue::GetChildAtIndex (uint32_t idx,
DynamicValueType use_dynamic,
bool can_create_synthetic);
The new "can_create_synthetic" will allow you to create child values that
aren't actually a part of the original type. So if you code like:
int *foo_ptr = ...
And you have a SBValue that contains the value for "foo_ptr":
SBValue foo_value = ...
You can now get the "foo_ptr[12]" item by doing this:
v = foo_value.GetChiltAtIndex (12, lldb.eNoDynamicValues, True);
Normall the "foo_value" would only have one child value (an integer), but
we can create "synthetic" child values by treating the pointer as an array.
Likewise if you have code like:
int array[2];
array_value = ....
v = array_value.GetChiltAtIndex (0); // Success, v will be valid
v = array_value.GetChiltAtIndex (1); // Success, v will be valid
v = array_value.GetChiltAtIndex (2); // Fail, v won't be valid, "2" is not a valid zero based index in "array"
But if you use the ability to create synthetic children:
v = array_value.GetChiltAtIndex (0, lldb.eNoDynamicValues, True); // Success, v will be valid
v = array_value.GetChiltAtIndex (1, lldb.eNoDynamicValues, True); // Success, v will be valid
v = array_value.GetChiltAtIndex (2, lldb.eNoDynamicValues, True); // Success, v will be valid
llvm-svn: 135292
2011-07-15 19:31:49 +00:00
|
|
|
SBValue SBValue::GetChildAtIndex(uint32_t idx,
|
|
|
|
lldb::DynamicValueType use_dynamic,
|
|
|
|
bool can_create_synthetic) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, idx, use_dynamic, can_create_synthetic);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
lldb::ValueObjectSP child_sp;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-04 02:27:34 +00:00
|
|
|
if (value_sp) {
|
2013-05-15 02:16:21 +00:00
|
|
|
const bool can_create = true;
|
2023-05-28 19:16:49 -07:00
|
|
|
child_sp = value_sp->GetChildAtIndex(idx);
|
2013-05-15 02:16:21 +00:00
|
|
|
if (can_create_synthetic && !child_sp) {
|
2015-02-26 23:55:39 +00:00
|
|
|
child_sp = value_sp->GetSyntheticArrayMember(idx, can_create);
|
2011-04-16 00:01:13 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2012-10-22 18:18:36 +00:00
|
|
|
SBValue sb_value;
|
|
|
|
sb_value.SetSP(child_sp, use_dynamic, GetPreferSyntheticValue());
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2022-01-09 22:54:08 -08:00
|
|
|
return sb_value;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
uint32_t SBValue::GetIndexOfChildWithName(const char *name) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, name);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2010-10-31 03:01:06 +00:00
|
|
|
uint32_t idx = UINT32_MAX;
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-04 02:27:34 +00:00
|
|
|
if (value_sp) {
|
2023-05-28 15:52:06 -07:00
|
|
|
idx = value_sp->GetIndexOfChildWithName(name);
|
2011-05-20 23:51:26 +00:00
|
|
|
}
|
2010-10-31 03:01:06 +00:00
|
|
|
return idx;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
SBValue SBValue::GetChildMemberWithName(const char *name) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, name);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
lldb::DynamicValueType use_dynamic_value = eNoDynamicValues;
|
|
|
|
TargetSP target_sp;
|
|
|
|
if (m_opaque_sp)
|
|
|
|
target_sp = m_opaque_sp->GetTargetSP();
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
if (target_sp)
|
|
|
|
use_dynamic_value = target_sp->GetPreferDynamicValue();
|
2022-01-09 22:54:08 -08:00
|
|
|
return GetChildMemberWithName(name, use_dynamic_value);
|
2011-04-16 00:01:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
SBValue
|
2011-05-04 03:43:18 +00:00
|
|
|
SBValue::GetChildMemberWithName(const char *name,
|
|
|
|
lldb::DynamicValueType use_dynamic_value) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, name, use_dynamic_value);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
lldb::ValueObjectSP child_sp;
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2011-12-08 19:44:08 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-10-22 18:18:36 +00:00
|
|
|
if (value_sp) {
|
2023-05-28 18:48:32 -07:00
|
|
|
child_sp = value_sp->GetChildMemberWithName(name);
|
2011-12-08 19:44:08 +00:00
|
|
|
}
|
|
|
|
|
2012-10-22 18:18:36 +00:00
|
|
|
SBValue sb_value;
|
|
|
|
sb_value.SetSP(child_sp, use_dynamic_value, GetPreferSyntheticValue());
|
2011-12-08 19:44:08 +00:00
|
|
|
|
2022-01-09 22:54:08 -08:00
|
|
|
return sb_value;
|
2012-10-22 18:18:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
lldb::SBValue SBValue::GetDynamicValue(lldb::DynamicValueType use_dynamic) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, use_dynamic);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2012-10-22 18:18:36 +00:00
|
|
|
SBValue value_sb;
|
|
|
|
if (IsValid()) {
|
|
|
|
ValueImplSP proxy_sp(new ValueImpl(m_opaque_sp->GetRootSP(), use_dynamic,
|
|
|
|
m_opaque_sp->GetUseSynthetic()));
|
|
|
|
value_sb.SetSP(proxy_sp);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2022-01-09 22:54:08 -08:00
|
|
|
return value_sb;
|
2012-10-22 18:18:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
lldb::SBValue SBValue::GetStaticValue() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2012-10-22 18:18:36 +00:00
|
|
|
SBValue value_sb;
|
|
|
|
if (IsValid()) {
|
|
|
|
ValueImplSP proxy_sp(new ValueImpl(m_opaque_sp->GetRootSP(),
|
|
|
|
eNoDynamicValues,
|
|
|
|
m_opaque_sp->GetUseSynthetic()));
|
|
|
|
value_sb.SetSP(proxy_sp);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2022-01-09 22:54:08 -08:00
|
|
|
return value_sb;
|
2012-10-22 18:18:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
lldb::SBValue SBValue::GetNonSyntheticValue() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2012-10-22 18:18:36 +00:00
|
|
|
SBValue value_sb;
|
|
|
|
if (IsValid()) {
|
|
|
|
ValueImplSP proxy_sp(new ValueImpl(m_opaque_sp->GetRootSP(),
|
|
|
|
m_opaque_sp->GetUseDynamic(), false));
|
|
|
|
value_sb.SetSP(proxy_sp);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2022-01-09 22:54:08 -08:00
|
|
|
return value_sb;
|
2012-10-22 18:18:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
lldb::DynamicValueType SBValue::GetPreferDynamicValue() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2012-03-27 02:35:13 +00:00
|
|
|
if (!IsValid())
|
2013-05-15 02:16:21 +00:00
|
|
|
return eNoDynamicValues;
|
|
|
|
return m_opaque_sp->GetUseDynamic();
|
2012-03-27 02:35:13 +00:00
|
|
|
}
|
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
void SBValue::SetPreferDynamicValue(lldb::DynamicValueType use_dynamic) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, use_dynamic);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2012-02-04 02:27:34 +00:00
|
|
|
if (IsValid())
|
2013-05-15 02:16:21 +00:00
|
|
|
return m_opaque_sp->SetUseDynamic(use_dynamic);
|
2011-12-08 19:44:08 +00:00
|
|
|
}
|
|
|
|
|
Because of our lifetime rules w.r.t. ValueObjects and ClusterManagers, synthetic children caching is a tricky area:
- if a synthetic child comes from the same hierarchy as its parent object, then it can't be cached by SharedPointer inside the synthetic provider, or it will cause a reference loop;
- but, if a synthetic child is made from whole cloth (e.g. from an expression, a memory region, ...), then it better be cached by SharedPointer, or it will be cleared out and cause an assert() to fail if used at a later point
For most cases of self-rooted synthetic children, we have a flag we set "IsSyntheticChildrenGenerated", but we were not using it to track caching. So, what ended up happening is each provider would set up its own cache, and if it got it wrong, a hard to diagnose crash would ensue
This patch fixes that by centralizing caching in ValueObjectSynthetic - if a provider returns a self-rooted child (as per the flag), then it gets cached centrally by the ValueObject itself
This cache is used only for lifetime management and not later retrieval of child values - a different cache handles that (because we might have a mix of self-rooted and properly nested child values for the same parent, we can't trivially use this lifetime cache for retrieval)
Fixes rdar://26480007
llvm-svn: 274683
2016-07-06 21:24:28 +00:00
|
|
|
bool SBValue::GetPreferSyntheticValue() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
Because of our lifetime rules w.r.t. ValueObjects and ClusterManagers, synthetic children caching is a tricky area:
- if a synthetic child comes from the same hierarchy as its parent object, then it can't be cached by SharedPointer inside the synthetic provider, or it will cause a reference loop;
- but, if a synthetic child is made from whole cloth (e.g. from an expression, a memory region, ...), then it better be cached by SharedPointer, or it will be cleared out and cause an assert() to fail if used at a later point
For most cases of self-rooted synthetic children, we have a flag we set "IsSyntheticChildrenGenerated", but we were not using it to track caching. So, what ended up happening is each provider would set up its own cache, and if it got it wrong, a hard to diagnose crash would ensue
This patch fixes that by centralizing caching in ValueObjectSynthetic - if a provider returns a self-rooted child (as per the flag), then it gets cached centrally by the ValueObject itself
This cache is used only for lifetime management and not later retrieval of child values - a different cache handles that (because we might have a mix of self-rooted and properly nested child values for the same parent, we can't trivially use this lifetime cache for retrieval)
Fixes rdar://26480007
llvm-svn: 274683
2016-07-06 21:24:28 +00:00
|
|
|
if (!IsValid())
|
|
|
|
return false;
|
2012-10-22 18:18:36 +00:00
|
|
|
return m_opaque_sp->GetUseSynthetic();
|
Because of our lifetime rules w.r.t. ValueObjects and ClusterManagers, synthetic children caching is a tricky area:
- if a synthetic child comes from the same hierarchy as its parent object, then it can't be cached by SharedPointer inside the synthetic provider, or it will cause a reference loop;
- but, if a synthetic child is made from whole cloth (e.g. from an expression, a memory region, ...), then it better be cached by SharedPointer, or it will be cleared out and cause an assert() to fail if used at a later point
For most cases of self-rooted synthetic children, we have a flag we set "IsSyntheticChildrenGenerated", but we were not using it to track caching. So, what ended up happening is each provider would set up its own cache, and if it got it wrong, a hard to diagnose crash would ensue
This patch fixes that by centralizing caching in ValueObjectSynthetic - if a provider returns a self-rooted child (as per the flag), then it gets cached centrally by the ValueObject itself
This cache is used only for lifetime management and not later retrieval of child values - a different cache handles that (because we might have a mix of self-rooted and properly nested child values for the same parent, we can't trivially use this lifetime cache for retrieval)
Fixes rdar://26480007
llvm-svn: 274683
2016-07-06 21:24:28 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
Because of our lifetime rules w.r.t. ValueObjects and ClusterManagers, synthetic children caching is a tricky area:
- if a synthetic child comes from the same hierarchy as its parent object, then it can't be cached by SharedPointer inside the synthetic provider, or it will cause a reference loop;
- but, if a synthetic child is made from whole cloth (e.g. from an expression, a memory region, ...), then it better be cached by SharedPointer, or it will be cleared out and cause an assert() to fail if used at a later point
For most cases of self-rooted synthetic children, we have a flag we set "IsSyntheticChildrenGenerated", but we were not using it to track caching. So, what ended up happening is each provider would set up its own cache, and if it got it wrong, a hard to diagnose crash would ensue
This patch fixes that by centralizing caching in ValueObjectSynthetic - if a provider returns a self-rooted child (as per the flag), then it gets cached centrally by the ValueObject itself
This cache is used only for lifetime management and not later retrieval of child values - a different cache handles that (because we might have a mix of self-rooted and properly nested child values for the same parent, we can't trivially use this lifetime cache for retrieval)
Fixes rdar://26480007
llvm-svn: 274683
2016-07-06 21:24:28 +00:00
|
|
|
void SBValue::SetPreferSyntheticValue(bool use_synthetic) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, use_synthetic);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
Because of our lifetime rules w.r.t. ValueObjects and ClusterManagers, synthetic children caching is a tricky area:
- if a synthetic child comes from the same hierarchy as its parent object, then it can't be cached by SharedPointer inside the synthetic provider, or it will cause a reference loop;
- but, if a synthetic child is made from whole cloth (e.g. from an expression, a memory region, ...), then it better be cached by SharedPointer, or it will be cleared out and cause an assert() to fail if used at a later point
For most cases of self-rooted synthetic children, we have a flag we set "IsSyntheticChildrenGenerated", but we were not using it to track caching. So, what ended up happening is each provider would set up its own cache, and if it got it wrong, a hard to diagnose crash would ensue
This patch fixes that by centralizing caching in ValueObjectSynthetic - if a provider returns a self-rooted child (as per the flag), then it gets cached centrally by the ValueObject itself
This cache is used only for lifetime management and not later retrieval of child values - a different cache handles that (because we might have a mix of self-rooted and properly nested child values for the same parent, we can't trivially use this lifetime cache for retrieval)
Fixes rdar://26480007
llvm-svn: 274683
2016-07-06 21:24:28 +00:00
|
|
|
if (IsValid())
|
2012-10-22 18:18:36 +00:00
|
|
|
return m_opaque_sp->SetUseSynthetic(use_synthetic);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
Because of our lifetime rules w.r.t. ValueObjects and ClusterManagers, synthetic children caching is a tricky area:
- if a synthetic child comes from the same hierarchy as its parent object, then it can't be cached by SharedPointer inside the synthetic provider, or it will cause a reference loop;
- but, if a synthetic child is made from whole cloth (e.g. from an expression, a memory region, ...), then it better be cached by SharedPointer, or it will be cleared out and cause an assert() to fail if used at a later point
For most cases of self-rooted synthetic children, we have a flag we set "IsSyntheticChildrenGenerated", but we were not using it to track caching. So, what ended up happening is each provider would set up its own cache, and if it got it wrong, a hard to diagnose crash would ensue
This patch fixes that by centralizing caching in ValueObjectSynthetic - if a provider returns a self-rooted child (as per the flag), then it gets cached centrally by the ValueObject itself
This cache is used only for lifetime management and not later retrieval of child values - a different cache handles that (because we might have a mix of self-rooted and properly nested child values for the same parent, we can't trivially use this lifetime cache for retrieval)
Fixes rdar://26480007
llvm-svn: 274683
2016-07-06 21:24:28 +00:00
|
|
|
bool SBValue::IsDynamic() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
Because of our lifetime rules w.r.t. ValueObjects and ClusterManagers, synthetic children caching is a tricky area:
- if a synthetic child comes from the same hierarchy as its parent object, then it can't be cached by SharedPointer inside the synthetic provider, or it will cause a reference loop;
- but, if a synthetic child is made from whole cloth (e.g. from an expression, a memory region, ...), then it better be cached by SharedPointer, or it will be cleared out and cause an assert() to fail if used at a later point
For most cases of self-rooted synthetic children, we have a flag we set "IsSyntheticChildrenGenerated", but we were not using it to track caching. So, what ended up happening is each provider would set up its own cache, and if it got it wrong, a hard to diagnose crash would ensue
This patch fixes that by centralizing caching in ValueObjectSynthetic - if a provider returns a self-rooted child (as per the flag), then it gets cached centrally by the ValueObject itself
This cache is used only for lifetime management and not later retrieval of child values - a different cache handles that (because we might have a mix of self-rooted and properly nested child values for the same parent, we can't trivially use this lifetime cache for retrieval)
Fixes rdar://26480007
llvm-svn: 274683
2016-07-06 21:24:28 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
|
|
|
if (value_sp)
|
|
|
|
return value_sp->IsDynamic();
|
|
|
|
return false;
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-07-15 02:26:42 +00:00
|
|
|
bool SBValue::IsSynthetic() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-04 02:27:34 +00:00
|
|
|
if (value_sp)
|
Because of our lifetime rules w.r.t. ValueObjects and ClusterManagers, synthetic children caching is a tricky area:
- if a synthetic child comes from the same hierarchy as its parent object, then it can't be cached by SharedPointer inside the synthetic provider, or it will cause a reference loop;
- but, if a synthetic child is made from whole cloth (e.g. from an expression, a memory region, ...), then it better be cached by SharedPointer, or it will be cleared out and cause an assert() to fail if used at a later point
For most cases of self-rooted synthetic children, we have a flag we set "IsSyntheticChildrenGenerated", but we were not using it to track caching. So, what ended up happening is each provider would set up its own cache, and if it got it wrong, a hard to diagnose crash would ensue
This patch fixes that by centralizing caching in ValueObjectSynthetic - if a provider returns a self-rooted child (as per the flag), then it gets cached centrally by the ValueObject itself
This cache is used only for lifetime management and not later retrieval of child values - a different cache handles that (because we might have a mix of self-rooted and properly nested child values for the same parent, we can't trivially use this lifetime cache for retrieval)
Fixes rdar://26480007
llvm-svn: 274683
2016-07-06 21:24:28 +00:00
|
|
|
return value_sp->IsSynthetic();
|
2012-10-22 18:18:36 +00:00
|
|
|
return false;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
Because of our lifetime rules w.r.t. ValueObjects and ClusterManagers, synthetic children caching is a tricky area:
- if a synthetic child comes from the same hierarchy as its parent object, then it can't be cached by SharedPointer inside the synthetic provider, or it will cause a reference loop;
- but, if a synthetic child is made from whole cloth (e.g. from an expression, a memory region, ...), then it better be cached by SharedPointer, or it will be cleared out and cause an assert() to fail if used at a later point
For most cases of self-rooted synthetic children, we have a flag we set "IsSyntheticChildrenGenerated", but we were not using it to track caching. So, what ended up happening is each provider would set up its own cache, and if it got it wrong, a hard to diagnose crash would ensue
This patch fixes that by centralizing caching in ValueObjectSynthetic - if a provider returns a self-rooted child (as per the flag), then it gets cached centrally by the ValueObject itself
This cache is used only for lifetime management and not later retrieval of child values - a different cache handles that (because we might have a mix of self-rooted and properly nested child values for the same parent, we can't trivially use this lifetime cache for retrieval)
Fixes rdar://26480007
llvm-svn: 274683
2016-07-06 21:24:28 +00:00
|
|
|
bool SBValue::IsSyntheticChildrenGenerated() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-04 02:27:34 +00:00
|
|
|
if (value_sp)
|
2013-05-15 02:16:21 +00:00
|
|
|
return value_sp->IsSyntheticChildrenGenerated();
|
2012-10-22 18:18:36 +00:00
|
|
|
return false;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2012-10-22 18:18:36 +00:00
|
|
|
void SBValue::SetSyntheticChildrenGenerated(bool is) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, is);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
2012-10-22 18:18:36 +00:00
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2014-04-04 04:06:10 +00:00
|
|
|
if (value_sp)
|
|
|
|
return value_sp->SetSyntheticChildrenGenerated(is);
|
2011-07-15 02:26:42 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-08-04 01:41:02 +00:00
|
|
|
lldb::SBValue SBValue::GetValueForExpressionPath(const char *expr_path) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, expr_path);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
lldb::ValueObjectSP child_sp;
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-04 02:27:34 +00:00
|
|
|
if (value_sp) {
|
2013-10-31 18:57:50 +00:00
|
|
|
// using default values for all the fancy options, just do it if you can
|
|
|
|
child_sp = value_sp->GetValueForExpressionPath(expr_path);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2013-10-31 18:57:50 +00:00
|
|
|
SBValue sb_value;
|
2013-05-15 02:16:21 +00:00
|
|
|
sb_value.SetSP(child_sp, GetPreferDynamicValue(), GetPreferSyntheticValue());
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2022-01-09 22:54:08 -08:00
|
|
|
return sb_value;
|
2011-08-04 01:41:02 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-08-04 01:41:02 +00:00
|
|
|
int64_t SBValue::GetValueAsSigned(SBError &error, int64_t fail_value) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, error, fail_value);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2011-08-12 23:34:31 +00:00
|
|
|
error.Clear();
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-04 02:27:34 +00:00
|
|
|
if (value_sp) {
|
2013-10-31 18:57:50 +00:00
|
|
|
bool success = true;
|
|
|
|
uint64_t ret_val = fail_value;
|
|
|
|
ret_val = value_sp->GetValueAsSigned(fail_value, &success);
|
|
|
|
if (!success)
|
2013-05-15 02:16:21 +00:00
|
|
|
error.SetErrorString("could not resolve value");
|
2013-10-31 18:57:50 +00:00
|
|
|
return ret_val;
|
2013-05-15 02:16:21 +00:00
|
|
|
} else
|
|
|
|
error.SetErrorStringWithFormat("could not get SBValue: %s",
|
|
|
|
locker.GetError().AsCString());
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-08-04 01:41:02 +00:00
|
|
|
return fail_value;
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-08-03 22:57:10 +00:00
|
|
|
uint64_t SBValue::GetValueAsUnsigned(SBError &error, uint64_t fail_value) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, error, fail_value);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2011-08-12 23:34:31 +00:00
|
|
|
error.Clear();
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-04 02:27:34 +00:00
|
|
|
if (value_sp) {
|
2013-10-31 18:57:50 +00:00
|
|
|
bool success = true;
|
|
|
|
uint64_t ret_val = fail_value;
|
|
|
|
ret_val = value_sp->GetValueAsUnsigned(fail_value, &success);
|
|
|
|
if (!success)
|
|
|
|
error.SetErrorString("could not resolve value");
|
|
|
|
return ret_val;
|
2011-08-03 22:57:10 +00:00
|
|
|
} else
|
2013-05-15 02:16:21 +00:00
|
|
|
error.SetErrorStringWithFormat("could not get SBValue: %s",
|
|
|
|
locker.GetError().AsCString());
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-08-03 22:57:10 +00:00
|
|
|
return fail_value;
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-08-03 22:57:10 +00:00
|
|
|
int64_t SBValue::GetValueAsSigned(int64_t fail_value) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, fail_value);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-04 02:27:34 +00:00
|
|
|
if (value_sp) {
|
2013-10-31 18:57:50 +00:00
|
|
|
return value_sp->GetValueAsSigned(fail_value);
|
2011-08-03 22:57:10 +00:00
|
|
|
}
|
|
|
|
return fail_value;
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-10-23 01:50:10 +00:00
|
|
|
uint64_t SBValue::GetValueAsUnsigned(uint64_t fail_value) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, fail_value);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-10-23 01:50:10 +00:00
|
|
|
if (value_sp) {
|
|
|
|
return value_sp->GetValueAsUnsigned(fail_value);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2012-10-23 01:50:10 +00:00
|
|
|
return fail_value;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
[lldb] Add SBValue::GetValueAsAddress API (#90144)
I previously added this API via https://reviews.llvm.org/D142792 in
2023, along with changes to the ValueObject class to treat pointer types
as addresses, and to annotate those ValueObjects with the original
uint64_t byte sequence AND the name of the symbol once stripped, if that
points to a symbol.
I did this unconditionally for all pointer type ValueObjects, and it
caused several regressions in the Objective-C data formatters which have
a ValueObject of an object, it has the address of its class -- but with
ObjC, sometimes it is a "tagged pointer" which is metadata, not an
actual pointer. (e.g. a small NSInteger value is stored entirely in the
tagged pointer, instead of a separate object) Treating these
not-addresses as addresses -- clearing the non-addressable-bits -- is
invalid.
The original version of this patch we're using downstream only does this
bits clearing for pointer types that are specifically decorated with the
pointerauth typequal, but not all of those clang changes are upstreamed
to github main yet, so I tried this simpler approach and hit the tagged
pointer issue and bailed on the whole patch.
This patch, however, is simply adding SBValue::GetValueAsAddress so
script writers who know that an SBValue has an address in memory, can
strip off any metadata. It's an important API to have for script writers
when AArch64 ptrauth is in use, so I'm going to put this part of the
patch back on github main now until we can get the rest of that original
patch upstreamed.
2024-04-25 16:42:33 -07:00
|
|
|
lldb::addr_t SBValue::GetValueAsAddress() {
|
|
|
|
addr_t fail_value = LLDB_INVALID_ADDRESS;
|
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
|
|
|
if (value_sp) {
|
|
|
|
bool success = true;
|
|
|
|
uint64_t ret_val = fail_value;
|
|
|
|
ret_val = value_sp->GetValueAsUnsigned(fail_value, &success);
|
|
|
|
if (!success)
|
|
|
|
return fail_value;
|
|
|
|
ProcessSP process_sp = m_opaque_sp->GetProcessSP();
|
|
|
|
if (!process_sp)
|
|
|
|
return ret_val;
|
|
|
|
return process_sp->FixDataAddress(ret_val);
|
|
|
|
}
|
|
|
|
|
|
|
|
return fail_value;
|
|
|
|
}
|
|
|
|
|
2014-04-04 04:06:10 +00:00
|
|
|
bool SBValue::MightHaveChildren() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2015-02-11 02:35:39 +00:00
|
|
|
bool has_children = false;
|
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
|
|
|
if (value_sp)
|
2012-10-23 01:50:10 +00:00
|
|
|
has_children = value_sp->MightHaveChildren();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-10-23 01:50:10 +00:00
|
|
|
return has_children;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2015-02-11 02:35:39 +00:00
|
|
|
bool SBValue::IsRuntimeSupportValue() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2010-10-31 03:01:06 +00:00
|
|
|
bool is_support = false;
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-04 02:27:34 +00:00
|
|
|
if (value_sp)
|
2015-02-11 02:35:39 +00:00
|
|
|
is_support = value_sp->IsRuntimeSupportValue();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-02-11 02:35:39 +00:00
|
|
|
return is_support;
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-03-06 00:06:00 +00:00
|
|
|
uint32_t SBValue::GetNumChildren() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
|
|
|
return GetNumChildren(UINT32_MAX);
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-10-21 19:28:08 +00:00
|
|
|
uint32_t SBValue::GetNumChildren(uint32_t max) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, max);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
uint32_t num_children = 0;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-04 02:27:34 +00:00
|
|
|
if (value_sp)
|
2024-03-08 10:39:34 -08:00
|
|
|
num_children = value_sp->GetNumChildrenIgnoringErrors(max);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
return num_children;
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
SBValue SBValue::Dereference() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2010-10-31 03:01:06 +00:00
|
|
|
SBValue sb_value;
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-04 02:27:34 +00:00
|
|
|
if (value_sp) {
|
2017-05-12 04:51:55 +00:00
|
|
|
Status error;
|
2013-08-26 23:57:52 +00:00
|
|
|
sb_value = value_sp->Dereference(error);
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2022-01-09 22:54:08 -08:00
|
|
|
return sb_value;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
2015-07-27 21:51:56 +00:00
|
|
|
// Deprecated - please use GetType().IsPointerType() instead.
|
2019-03-06 00:06:00 +00:00
|
|
|
bool SBValue::TypeIsPointerType() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
|
|
|
return GetType().IsPointerType();
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
void *SBValue::GetOpaqueType() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2011-07-29 19:53:35 +00:00
|
|
|
ValueLocker locker;
|
2013-03-27 23:08:40 +00:00
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2013-05-15 02:16:21 +00:00
|
|
|
if (value_sp)
|
|
|
|
return value_sp->GetCompilerType().GetOpaqueQualType();
|
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
2019-05-23 11:14:47 +00:00
|
|
|
return nullptr;
|
2011-07-29 19:53:35 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2014-04-04 04:06:10 +00:00
|
|
|
lldb::SBTarget SBValue::GetTarget() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2012-01-30 02:53:15 +00:00
|
|
|
SBTarget sb_target;
|
2013-11-04 09:33:30 +00:00
|
|
|
TargetSP target_sp;
|
2013-05-15 02:16:21 +00:00
|
|
|
if (m_opaque_sp) {
|
|
|
|
target_sp = m_opaque_sp->GetTargetSP();
|
2014-04-04 04:06:10 +00:00
|
|
|
sb_target.SetSP(target_sp);
|
2011-07-29 19:53:35 +00:00
|
|
|
}
|
2019-03-07 22:47:13 +00:00
|
|
|
|
2022-01-09 22:54:08 -08:00
|
|
|
return sb_target;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2012-10-22 18:18:36 +00:00
|
|
|
lldb::SBProcess SBValue::GetProcess() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2012-01-30 07:41:31 +00:00
|
|
|
SBProcess sb_process;
|
2012-10-22 18:18:36 +00:00
|
|
|
ProcessSP process_sp;
|
|
|
|
if (m_opaque_sp) {
|
|
|
|
process_sp = m_opaque_sp->GetProcessSP();
|
|
|
|
sb_process.SetSP(process_sp);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2019-03-07 22:47:13 +00:00
|
|
|
|
2022-01-09 22:54:08 -08:00
|
|
|
return sb_process;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2012-10-22 18:18:36 +00:00
|
|
|
lldb::SBThread SBValue::GetThread() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2012-01-30 02:53:15 +00:00
|
|
|
SBThread sb_thread;
|
2012-10-22 18:18:36 +00:00
|
|
|
ThreadSP thread_sp;
|
|
|
|
if (m_opaque_sp) {
|
|
|
|
thread_sp = m_opaque_sp->GetThreadSP();
|
|
|
|
sb_thread.SetThread(thread_sp);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2019-03-07 22:47:13 +00:00
|
|
|
|
2022-01-09 22:54:08 -08:00
|
|
|
return sb_thread;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
lldb::SBFrame SBValue::GetFrame() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2010-10-31 03:01:06 +00:00
|
|
|
SBFrame sb_frame;
|
2013-05-15 02:16:21 +00:00
|
|
|
StackFrameSP frame_sp;
|
2012-02-04 02:27:34 +00:00
|
|
|
if (m_opaque_sp) {
|
|
|
|
frame_sp = m_opaque_sp->GetFrameSP();
|
|
|
|
sb_frame.SetFrameSP(frame_sp);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2019-03-07 22:47:13 +00:00
|
|
|
|
2022-01-09 22:54:08 -08:00
|
|
|
return sb_frame;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
lldb::ValueObjectSP SBValue::GetSP(ValueLocker &locker) const {
|
2023-02-28 16:38:50 -08:00
|
|
|
// IsValid means that the SBValue has a value in it. But that's not the
|
|
|
|
// only time that ValueObjects are useful. We also want to return the value
|
|
|
|
// if there's an error state in it.
|
2023-10-30 17:46:18 -07:00
|
|
|
if (!m_opaque_sp || (!m_opaque_sp->IsValid()
|
|
|
|
&& (m_opaque_sp->GetRootSP()
|
2023-02-28 16:38:50 -08:00
|
|
|
&& !m_opaque_sp->GetRootSP()->GetError().Fail()))) {
|
2011-11-13 06:57:31 +00:00
|
|
|
locker.GetError().SetErrorString("No value");
|
2012-10-22 18:18:36 +00:00
|
|
|
return ValueObjectSP();
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2013-05-15 02:16:21 +00:00
|
|
|
return locker.GetLockedSP(*m_opaque_sp.get());
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2012-02-04 02:27:34 +00:00
|
|
|
lldb::ValueObjectSP SBValue::GetSP() const {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
Because of our lifetime rules w.r.t. ValueObjects and ClusterManagers, synthetic children caching is a tricky area:
- if a synthetic child comes from the same hierarchy as its parent object, then it can't be cached by SharedPointer inside the synthetic provider, or it will cause a reference loop;
- but, if a synthetic child is made from whole cloth (e.g. from an expression, a memory region, ...), then it better be cached by SharedPointer, or it will be cleared out and cause an assert() to fail if used at a later point
For most cases of self-rooted synthetic children, we have a flag we set "IsSyntheticChildrenGenerated", but we were not using it to track caching. So, what ended up happening is each provider would set up its own cache, and if it got it wrong, a hard to diagnose crash would ensue
This patch fixes that by centralizing caching in ValueObjectSynthetic - if a provider returns a self-rooted child (as per the flag), then it gets cached centrally by the ValueObject itself
This cache is used only for lifetime management and not later retrieval of child values - a different cache handles that (because we might have a mix of self-rooted and properly nested child values for the same parent, we can't trivially use this lifetime cache for retrieval)
Fixes rdar://26480007
llvm-svn: 274683
2016-07-06 21:24:28 +00:00
|
|
|
ValueLocker locker;
|
2022-01-09 22:54:08 -08:00
|
|
|
return GetSP(locker);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
void SBValue::SetSP(ValueImplSP impl_sp) { m_opaque_sp = impl_sp; }
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-02-04 02:27:34 +00:00
|
|
|
void SBValue::SetSP(const lldb::ValueObjectSP &sp) {
|
2016-09-06 20:57:50 +00:00
|
|
|
if (sp) {
|
2012-10-22 18:18:36 +00:00
|
|
|
lldb::TargetSP target_sp(sp->GetTargetSP());
|
2012-02-17 07:49:44 +00:00
|
|
|
if (target_sp) {
|
2012-10-22 18:18:36 +00:00
|
|
|
lldb::DynamicValueType use_dynamic = target_sp->GetPreferDynamicValue();
|
|
|
|
bool use_synthetic =
|
|
|
|
target_sp->TargetProperties::GetEnableSyntheticValue();
|
2013-05-15 02:16:21 +00:00
|
|
|
m_opaque_sp = ValueImplSP(new ValueImpl(sp, use_dynamic, use_synthetic));
|
2016-09-06 20:57:50 +00:00
|
|
|
} else
|
2011-11-13 06:57:31 +00:00
|
|
|
m_opaque_sp = ValueImplSP(new ValueImpl(sp, eNoDynamicValues, true));
|
2016-09-06 20:57:50 +00:00
|
|
|
} else
|
2012-10-22 18:18:36 +00:00
|
|
|
m_opaque_sp = ValueImplSP(new ValueImpl(sp, eNoDynamicValues, false));
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2012-02-04 02:27:34 +00:00
|
|
|
void SBValue::SetSP(const lldb::ValueObjectSP &sp,
|
2012-10-22 18:18:36 +00:00
|
|
|
lldb::DynamicValueType use_dynamic) {
|
2016-09-06 20:57:50 +00:00
|
|
|
if (sp) {
|
2012-10-22 18:18:36 +00:00
|
|
|
lldb::TargetSP target_sp(sp->GetTargetSP());
|
2012-02-17 07:49:44 +00:00
|
|
|
if (target_sp) {
|
2012-10-22 18:18:36 +00:00
|
|
|
bool use_synthetic =
|
|
|
|
target_sp->TargetProperties::GetEnableSyntheticValue();
|
|
|
|
SetSP(sp, use_dynamic, use_synthetic);
|
2016-09-06 20:57:50 +00:00
|
|
|
} else
|
2012-10-22 18:18:36 +00:00
|
|
|
SetSP(sp, use_dynamic, true);
|
2016-09-06 20:57:50 +00:00
|
|
|
} else
|
2012-10-22 18:18:36 +00:00
|
|
|
SetSP(sp, use_dynamic, false);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2012-10-22 18:18:36 +00:00
|
|
|
void SBValue::SetSP(const lldb::ValueObjectSP &sp, bool use_synthetic) {
|
2016-09-06 20:57:50 +00:00
|
|
|
if (sp) {
|
2012-10-22 18:18:36 +00:00
|
|
|
lldb::TargetSP target_sp(sp->GetTargetSP());
|
2012-02-17 07:49:44 +00:00
|
|
|
if (target_sp) {
|
2012-10-22 18:18:36 +00:00
|
|
|
lldb::DynamicValueType use_dynamic = target_sp->GetPreferDynamicValue();
|
|
|
|
SetSP(sp, use_dynamic, use_synthetic);
|
2016-09-06 20:57:50 +00:00
|
|
|
} else
|
2012-10-22 18:18:36 +00:00
|
|
|
SetSP(sp, eNoDynamicValues, use_synthetic);
|
2016-09-06 20:57:50 +00:00
|
|
|
} else
|
2012-10-22 18:18:36 +00:00
|
|
|
SetSP(sp, eNoDynamicValues, use_synthetic);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2012-02-04 02:27:34 +00:00
|
|
|
void SBValue::SetSP(const lldb::ValueObjectSP &sp,
|
2012-10-22 18:18:36 +00:00
|
|
|
lldb::DynamicValueType use_dynamic, bool use_synthetic) {
|
2013-05-15 02:16:21 +00:00
|
|
|
m_opaque_sp = ValueImplSP(new ValueImpl(sp, use_dynamic, use_synthetic));
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2012-02-04 02:27:34 +00:00
|
|
|
void SBValue::SetSP(const lldb::ValueObjectSP &sp,
|
2012-10-22 18:18:36 +00:00
|
|
|
lldb::DynamicValueType use_dynamic, bool use_synthetic,
|
2013-05-15 02:16:21 +00:00
|
|
|
const char *name) {
|
|
|
|
m_opaque_sp =
|
|
|
|
ValueImplSP(new ValueImpl(sp, use_dynamic, use_synthetic, name));
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
A few of the issue I have been trying to track down and fix have been due to
the way LLDB lazily gets complete definitions for types within the debug info.
When we run across a class/struct/union definition in the DWARF, we will only
parse the full definition if we need to. This works fine for top level types
that are assigned directly to variables and arguments, but when we have a
variable with a class, lets say "A" for this example, that has a member:
"B *m_b". Initially we don't need to hunt down a definition for this class
unless we are ever asked to do something with it ("expr m_b->getDecl()" for
example). With my previous approach to lazy type completion, we would be able
to take a "A *a" and get a complete type for it, but we wouldn't be able to
then do an "a->m_b->getDecl()" unless we always expanded all types within a
class prior to handing out the type. Expanding everything is very costly and
it would be great if there were a better way.
A few months ago I worked with the llvm/clang folks to have the
ExternalASTSource class be able to complete classes if there weren't completed
yet:
class ExternalASTSource {
....
virtual void
CompleteType (clang::TagDecl *Tag);
virtual void
CompleteType (clang::ObjCInterfaceDecl *Class);
};
This was great, because we can now have the class that is producing the AST
(SymbolFileDWARF and SymbolFileDWARFDebugMap) sign up as external AST sources
and the object that creates the forward declaration types can now also
complete them anywhere within the clang type system.
This patch makes a few major changes:
- lldb_private::Module classes now own the AST context. Previously the TypeList
objects did.
- The DWARF parsers now sign up as an external AST sources so they can complete
types.
- All of the pure clang type system wrapper code we have in LLDB (ClangASTContext,
ClangASTType, and more) can now be iterating through children of any type,
and if a class/union/struct type (clang::RecordType or ObjC interface)
is found that is incomplete, we can ask the AST to get the definition.
- The SymbolFileDWARFDebugMap class now will create and use a single AST that
all child SymbolFileDWARF classes will share (much like what happens when
we have a complete linked DWARF for an executable).
We will need to modify some of the ClangUserExpression code to take more
advantage of this completion ability in the near future. Meanwhile we should
be better off now that we can be accessing any children of variables through
pointers and always be able to resolve the clang type if needed.
llvm-svn: 123613
2011-01-17 03:46:26 +00:00
|
|
|
bool SBValue::GetExpressionPath(SBStream &description) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, description);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-04 02:27:34 +00:00
|
|
|
if (value_sp) {
|
2020-02-02 14:17:02 -08:00
|
|
|
value_sp->GetExpressionPath(description.ref());
|
2010-09-20 05:20:02 +00:00
|
|
|
return true;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
Because of our lifetime rules w.r.t. ValueObjects and ClusterManagers, synthetic children caching is a tricky area:
- if a synthetic child comes from the same hierarchy as its parent object, then it can't be cached by SharedPointer inside the synthetic provider, or it will cause a reference loop;
- but, if a synthetic child is made from whole cloth (e.g. from an expression, a memory region, ...), then it better be cached by SharedPointer, or it will be cleared out and cause an assert() to fail if used at a later point
For most cases of self-rooted synthetic children, we have a flag we set "IsSyntheticChildrenGenerated", but we were not using it to track caching. So, what ended up happening is each provider would set up its own cache, and if it got it wrong, a hard to diagnose crash would ensue
This patch fixes that by centralizing caching in ValueObjectSynthetic - if a provider returns a self-rooted child (as per the flag), then it gets cached centrally by the ValueObject itself
This cache is used only for lifetime management and not later retrieval of child values - a different cache handles that (because we might have a mix of self-rooted and properly nested child values for the same parent, we can't trivially use this lifetime cache for retrieval)
Fixes rdar://26480007
llvm-svn: 274683
2016-07-06 21:24:28 +00:00
|
|
|
return false;
|
2010-09-20 05:20:02 +00:00
|
|
|
}
|
2011-01-05 18:43:15 +00:00
|
|
|
|
2011-09-09 23:04:00 +00:00
|
|
|
bool SBValue::GetExpressionPath(SBStream &description,
|
2011-01-05 18:43:15 +00:00
|
|
|
bool qualify_cxx_base_classes) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, description, qualify_cxx_base_classes);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-04 02:27:34 +00:00
|
|
|
if (value_sp) {
|
2020-02-02 14:17:02 -08:00
|
|
|
value_sp->GetExpressionPath(description.ref());
|
2012-02-04 02:27:34 +00:00
|
|
|
return true;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2011-01-05 18:43:15 +00:00
|
|
|
return false;
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-03-06 00:06:00 +00:00
|
|
|
lldb::SBValue SBValue::EvaluateExpression(const char *expr) const {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, expr);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2019-02-05 09:14:36 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
|
|
|
if (!value_sp)
|
2022-01-09 22:54:08 -08:00
|
|
|
return SBValue();
|
2019-02-05 09:14:36 +00:00
|
|
|
|
|
|
|
lldb::TargetSP target_sp = value_sp->GetTargetSP();
|
|
|
|
if (!target_sp)
|
2022-01-09 22:54:08 -08:00
|
|
|
return SBValue();
|
2019-02-05 09:14:36 +00:00
|
|
|
|
|
|
|
lldb::SBExpressionOptions options;
|
|
|
|
options.SetFetchDynamicValue(target_sp->GetPreferDynamicValue());
|
|
|
|
options.SetUnwindOnError(true);
|
|
|
|
options.SetIgnoreBreakpoints(true);
|
|
|
|
|
2022-01-09 22:54:08 -08:00
|
|
|
return EvaluateExpression(expr, options, nullptr);
|
2019-02-05 09:14:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
lldb::SBValue
|
|
|
|
SBValue::EvaluateExpression(const char *expr,
|
|
|
|
const SBExpressionOptions &options) const {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, expr, options);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2022-01-09 22:54:08 -08:00
|
|
|
return EvaluateExpression(expr, options, nullptr);
|
2019-02-05 09:14:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
lldb::SBValue SBValue::EvaluateExpression(const char *expr,
|
|
|
|
const SBExpressionOptions &options,
|
|
|
|
const char *name) const {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, expr, options, name);
|
2019-02-05 09:14:36 +00:00
|
|
|
|
|
|
|
if (!expr || expr[0] == '\0') {
|
2022-01-09 22:54:08 -08:00
|
|
|
return SBValue();
|
2019-02-05 09:14:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
|
|
|
if (!value_sp) {
|
2022-01-09 22:54:08 -08:00
|
|
|
return SBValue();
|
2019-02-05 09:14:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
lldb::TargetSP target_sp = value_sp->GetTargetSP();
|
|
|
|
if (!target_sp) {
|
2022-01-09 22:54:08 -08:00
|
|
|
return SBValue();
|
2019-02-05 09:14:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(target_sp->GetAPIMutex());
|
|
|
|
ExecutionContext exe_ctx(target_sp.get());
|
|
|
|
|
|
|
|
StackFrame *frame = exe_ctx.GetFramePtr();
|
|
|
|
if (!frame) {
|
2022-01-09 22:54:08 -08:00
|
|
|
return SBValue();
|
2019-02-05 09:14:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
ValueObjectSP res_val_sp;
|
2019-03-07 22:47:13 +00:00
|
|
|
target_sp->EvaluateExpression(expr, frame, res_val_sp, options.ref(), nullptr,
|
|
|
|
value_sp.get());
|
2019-02-05 09:14:36 +00:00
|
|
|
|
|
|
|
if (name)
|
|
|
|
res_val_sp->SetName(ConstString(name));
|
|
|
|
|
|
|
|
SBValue result;
|
|
|
|
result.SetSP(res_val_sp, options.GetFetchDynamicValue());
|
2022-01-09 22:54:08 -08:00
|
|
|
return result;
|
2019-02-05 09:14:36 +00:00
|
|
|
}
|
|
|
|
|
2011-01-05 18:43:15 +00:00
|
|
|
bool SBValue::GetDescription(SBStream &description) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, description);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2011-01-05 18:43:15 +00:00
|
|
|
Stream &strm = description.ref();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2023-12-18 21:23:03 +01:00
|
|
|
if (value_sp) {
|
|
|
|
DumpValueObjectOptions options;
|
|
|
|
options.SetUseDynamicType(m_opaque_sp->GetUseDynamic());
|
|
|
|
options.SetUseSyntheticValue(m_opaque_sp->GetUseSynthetic());
|
2024-06-17 14:29:01 -07:00
|
|
|
if (llvm::Error error = value_sp->Dump(strm, options)) {
|
|
|
|
strm << "error: " << toString(std::move(error));
|
|
|
|
return false;
|
|
|
|
}
|
2023-12-18 21:23:03 +01:00
|
|
|
} else {
|
2013-05-15 02:16:21 +00:00
|
|
|
strm.PutCString("No value");
|
2023-12-18 21:23:03 +01:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
A few of the issue I have been trying to track down and fix have been due to
the way LLDB lazily gets complete definitions for types within the debug info.
When we run across a class/struct/union definition in the DWARF, we will only
parse the full definition if we need to. This works fine for top level types
that are assigned directly to variables and arguments, but when we have a
variable with a class, lets say "A" for this example, that has a member:
"B *m_b". Initially we don't need to hunt down a definition for this class
unless we are ever asked to do something with it ("expr m_b->getDecl()" for
example). With my previous approach to lazy type completion, we would be able
to take a "A *a" and get a complete type for it, but we wouldn't be able to
then do an "a->m_b->getDecl()" unless we always expanded all types within a
class prior to handing out the type. Expanding everything is very costly and
it would be great if there were a better way.
A few months ago I worked with the llvm/clang folks to have the
ExternalASTSource class be able to complete classes if there weren't completed
yet:
class ExternalASTSource {
....
virtual void
CompleteType (clang::TagDecl *Tag);
virtual void
CompleteType (clang::ObjCInterfaceDecl *Class);
};
This was great, because we can now have the class that is producing the AST
(SymbolFileDWARF and SymbolFileDWARFDebugMap) sign up as external AST sources
and the object that creates the forward declaration types can now also
complete them anywhere within the clang type system.
This patch makes a few major changes:
- lldb_private::Module classes now own the AST context. Previously the TypeList
objects did.
- The DWARF parsers now sign up as an external AST sources so they can complete
types.
- All of the pure clang type system wrapper code we have in LLDB (ClangASTContext,
ClangASTType, and more) can now be iterating through children of any type,
and if a class/union/struct type (clang::RecordType or ObjC interface)
is found that is incomplete, we can ask the AST to get the definition.
- The SymbolFileDWARFDebugMap class now will create and use a single AST that
all child SymbolFileDWARF classes will share (much like what happens when
we have a complete linked DWARF for an executable).
We will need to modify some of the ClangUserExpression code to take more
advantage of this completion ability in the near future. Meanwhile we should
be better off now that we can be accessing any children of variables through
pointers and always be able to resolve the clang type if needed.
llvm-svn: 123613
2011-01-17 03:46:26 +00:00
|
|
|
return true;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2012-02-04 02:27:34 +00:00
|
|
|
lldb::Format SBValue::GetFormat() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-04 02:27:34 +00:00
|
|
|
if (value_sp)
|
2013-05-15 02:16:21 +00:00
|
|
|
return value_sp->GetFormat();
|
|
|
|
return eFormatDefault;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
void SBValue::SetFormat(lldb::Format format) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, format);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
|
|
|
if (value_sp)
|
2013-03-27 23:08:40 +00:00
|
|
|
value_sp->SetFormat(format);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2014-04-04 04:06:10 +00:00
|
|
|
lldb::SBValue SBValue::AddressOf() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2012-10-22 18:18:36 +00:00
|
|
|
SBValue sb_value;
|
2014-04-04 04:06:10 +00:00
|
|
|
ValueLocker locker;
|
2013-05-15 02:16:21 +00:00
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2014-04-04 04:06:10 +00:00
|
|
|
if (value_sp) {
|
2017-05-12 04:51:55 +00:00
|
|
|
Status error;
|
2014-04-04 04:06:10 +00:00
|
|
|
sb_value.SetSP(value_sp->AddressOf(error), GetPreferDynamicValue(),
|
|
|
|
GetPreferSyntheticValue());
|
2011-08-09 22:38:07 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2022-01-09 22:54:08 -08:00
|
|
|
return sb_value;
|
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
|
|
|
lldb::addr_t SBValue::GetLoadAddress() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +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
|
|
|
lldb::addr_t value = LLDB_INVALID_ADDRESS;
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2024-06-13 09:14:17 -07:00
|
|
|
if (value_sp)
|
|
|
|
return value_sp->GetLoadAddress();
|
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 value;
|
|
|
|
}
|
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
|
|
|
lldb::SBAddress SBValue::GetAddress() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2012-02-04 02:27:34 +00:00
|
|
|
Address addr;
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-04 02:27:34 +00:00
|
|
|
if (value_sp) {
|
2013-05-15 02:16:21 +00:00
|
|
|
TargetSP target_sp(value_sp->GetTargetSP());
|
|
|
|
if (target_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
|
|
|
lldb::addr_t value = LLDB_INVALID_ADDRESS;
|
2013-10-31 18:57:50 +00:00
|
|
|
const bool scalar_is_load_address = true;
|
Redesign of the interaction between Python and frozen objects:
- introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from
a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored
in frozen objects ; now such reads transparently move from host to target as required
- as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also
removed code that enabled to recognize an expression result VO as such
- introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO
representing a T* or T[], and doing dereferences transparently
in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData
- as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it
en lieu of doing the raw read itself
- introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers,
this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory)
in public layer this returns an SBData, just like GetPointeeData()
- introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData
the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any
of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values
- added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing
Solved a bug where global pointers to global variables were not dereferenced correctly for display
New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128
Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command
Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type
of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file
addresses that generate file address children UNLESS we have a live process)
Updated help text for summary-string
Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers
Edited the syntax and help for some commands to have proper argument types
llvm-svn: 139160
2011-09-06 19:20:51 +00:00
|
|
|
AddressType addr_type;
|
2012-02-04 02:27:34 +00:00
|
|
|
value = value_sp->GetAddressOf(scalar_is_load_address, &addr_type);
|
Redesign of the interaction between Python and frozen objects:
- introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from
a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored
in frozen objects ; now such reads transparently move from host to target as required
- as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also
removed code that enabled to recognize an expression result VO as such
- introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO
representing a T* or T[], and doing dereferences transparently
in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData
- as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it
en lieu of doing the raw read itself
- introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers,
this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory)
in public layer this returns an SBData, just like GetPointeeData()
- introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData
the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any
of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values
- added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing
Solved a bug where global pointers to global variables were not dereferenced correctly for display
New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128
Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command
Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type
of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file
addresses that generate file address children UNLESS we have a live process)
Updated help text for summary-string
Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers
Edited the syntax and help for some commands to have proper argument types
llvm-svn: 139160
2011-09-06 19:20:51 +00:00
|
|
|
if (addr_type == eAddressTypeFile) {
|
2012-02-24 01:59:29 +00:00
|
|
|
ModuleSP module_sp(value_sp->GetModule());
|
|
|
|
if (module_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
|
|
|
module_sp->ResolveFileAddress(value, addr);
|
|
|
|
} else if (addr_type == eAddressTypeLoad) {
|
2018-04-30 16:49:04 +00:00
|
|
|
// no need to check the return value on this.. if it can actually do
|
|
|
|
// the resolve addr will be in the form (section,offset), otherwise it
|
|
|
|
// will simply be returned as (NULL, value)
|
2012-10-22 18:18:36 +00:00
|
|
|
addr.SetLoadAddress(value, target_sp.get());
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2019-03-07 22:47:13 +00:00
|
|
|
|
2022-01-09 22:54:08 -08:00
|
|
|
return SBAddress(addr);
|
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
|
|
|
lldb::SBData SBValue::GetPointeeData(uint32_t item_idx, uint32_t item_count) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, item_idx, item_count);
|
2019-03-06 00:06:00 +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
|
|
|
lldb::SBData sb_data;
|
|
|
|
ValueLocker locker;
|
2013-05-15 02:16:21 +00:00
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-04 02:27:34 +00:00
|
|
|
if (value_sp) {
|
2013-05-15 02:16:21 +00:00
|
|
|
TargetSP target_sp(value_sp->GetTargetSP());
|
|
|
|
if (target_sp) {
|
|
|
|
DataExtractorSP data_sp(new DataExtractor());
|
|
|
|
value_sp->GetPointeeData(*data_sp, item_idx, item_count);
|
|
|
|
if (data_sp->GetByteSize() > 0)
|
|
|
|
*sb_data = data_sp;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-01-09 22:54:08 -08:00
|
|
|
return sb_data;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2013-04-13 01:21:23 +00:00
|
|
|
lldb::SBData SBValue::GetData() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +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
|
|
|
lldb::SBData sb_data;
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-02-04 02:27:34 +00:00
|
|
|
if (value_sp) {
|
2012-02-17 07:49:44 +00:00
|
|
|
DataExtractorSP data_sp(new DataExtractor());
|
2017-05-12 04:51:55 +00:00
|
|
|
Status error;
|
2012-02-17 07:49:44 +00:00
|
|
|
value_sp->GetData(*data_sp, error);
|
|
|
|
if (error.Success())
|
|
|
|
*sb_data = data_sp;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2022-01-09 22:54:08 -08:00
|
|
|
return sb_data;
|
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 SBValue::SetData(lldb::SBData &data, SBError &error) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, data, error);
|
2019-03-06 00:06:00 +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
|
|
|
ValueLocker locker;
|
2013-05-15 02:16:21 +00:00
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
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 ret = true;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-02-04 02:27:34 +00:00
|
|
|
if (value_sp) {
|
2013-05-15 02:16:21 +00:00
|
|
|
DataExtractor *data_extractor = data.get();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
if (!data_extractor) {
|
|
|
|
error.SetErrorString("No data to set");
|
2013-04-13 01:21:23 +00:00
|
|
|
ret = false;
|
2016-09-06 20:57:50 +00:00
|
|
|
} else {
|
2017-05-12 04:51:55 +00:00
|
|
|
Status set_error;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
value_sp->SetData(*data_extractor, set_error);
|
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 (!set_error.Success()) {
|
2013-05-15 02:16:21 +00:00
|
|
|
error.SetErrorStringWithFormat("Couldn't set data: %s",
|
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
|
|
|
set_error.AsCString());
|
2013-04-13 01:21:23 +00:00
|
|
|
ret = false;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
2013-05-15 02:16:21 +00:00
|
|
|
error.SetErrorStringWithFormat(
|
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
|
|
|
"Couldn't set data: could not get SBValue: %s",
|
|
|
|
locker.GetError().AsCString());
|
|
|
|
ret = false;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2012-02-04 02:27:34 +00:00
|
|
|
return ret;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2021-11-22 13:46:49 -08:00
|
|
|
lldb::SBValue SBValue::Clone(const char *new_name) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, new_name);
|
2021-11-22 13:46:49 -08:00
|
|
|
|
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
|
|
|
|
|
|
|
if (value_sp)
|
|
|
|
return lldb::SBValue(value_sp->Clone(ConstString(new_name)));
|
|
|
|
else
|
|
|
|
return lldb::SBValue();
|
|
|
|
}
|
|
|
|
|
2012-02-04 02:27:34 +00:00
|
|
|
lldb::SBDeclaration SBValue::GetDeclaration() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2012-02-04 02:27:34 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
2012-10-10 22:54:17 +00:00
|
|
|
SBDeclaration decl_sb;
|
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 (value_sp) {
|
2012-02-24 01:59:29 +00:00
|
|
|
Declaration decl;
|
|
|
|
if (value_sp->GetDeclaration(decl))
|
|
|
|
decl_sb.SetDeclaration(decl);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2022-01-09 22:54:08 -08:00
|
|
|
return decl_sb;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2012-02-24 01:59:29 +00:00
|
|
|
lldb::SBWatchpoint SBValue::Watch(bool resolve_location, bool read, bool write,
|
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
|
|
|
SBError &error) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, resolve_location, read, write, error);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2012-02-04 02:27:34 +00:00
|
|
|
SBWatchpoint sb_watchpoint;
|
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 the SBValue is not valid, there's no point in even trying to watch it.
|
2013-05-15 02:16:21 +00:00
|
|
|
ValueLocker locker;
|
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
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
|
|
|
TargetSP target_sp(GetTarget().GetSP());
|
|
|
|
if (value_sp && target_sp) {
|
|
|
|
// Read and Write cannot both be false.
|
2012-02-04 02:27:34 +00:00
|
|
|
if (!read && !write)
|
2022-01-09 22:54:08 -08:00
|
|
|
return sb_watchpoint;
|
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 the value is not in scope, don't try and watch and invalid value
|
|
|
|
if (!IsInScope())
|
2022-01-09 22:54:08 -08:00
|
|
|
return sb_watchpoint;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-02-17 07:49:44 +00:00
|
|
|
addr_t addr = GetLoadAddress();
|
2012-02-04 02:27:34 +00:00
|
|
|
if (addr == LLDB_INVALID_ADDRESS)
|
2022-01-09 22:54:08 -08:00
|
|
|
return sb_watchpoint;
|
2012-02-04 02:27:34 +00:00
|
|
|
size_t byte_size = GetByteSize();
|
|
|
|
if (byte_size == 0)
|
2022-01-09 22:54:08 -08:00
|
|
|
return sb_watchpoint;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-02-04 02:27:34 +00:00
|
|
|
uint32_t watch_type = 0;
|
2023-09-21 10:21:53 +00:00
|
|
|
if (read) {
|
2012-02-04 02:27:34 +00:00
|
|
|
watch_type |= LLDB_WATCH_TYPE_READ;
|
2023-09-21 10:21:53 +00:00
|
|
|
// read + write, the most likely intention
|
|
|
|
// is to catch all writes to this, not just
|
|
|
|
// value modifications.
|
|
|
|
if (write)
|
|
|
|
watch_type |= LLDB_WATCH_TYPE_WRITE;
|
|
|
|
} else {
|
|
|
|
if (write)
|
|
|
|
watch_type |= LLDB_WATCH_TYPE_MODIFY;
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2017-05-12 04:51:55 +00:00
|
|
|
Status rc;
|
2012-02-17 07:49:44 +00:00
|
|
|
CompilerType type(value_sp->GetCompilerType());
|
2012-10-23 07:20:06 +00:00
|
|
|
WatchpointSP watchpoint_sp =
|
2012-02-17 07:49:44 +00:00
|
|
|
target_sp->CreateWatchpoint(addr, byte_size, &type, watch_type, rc);
|
|
|
|
error.SetError(rc);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-08-26 23:57:52 +00:00
|
|
|
if (watchpoint_sp) {
|
2012-02-04 02:27:34 +00:00
|
|
|
sb_watchpoint.SetSP(watchpoint_sp);
|
2012-10-10 22:54:17 +00:00
|
|
|
Declaration decl;
|
|
|
|
if (value_sp->GetDeclaration(decl)) {
|
2012-02-17 07:49:44 +00:00
|
|
|
if (decl.GetFile()) {
|
2012-02-04 02:27:34 +00:00
|
|
|
StreamString ss;
|
|
|
|
// True to show fullpath for declaration file.
|
|
|
|
decl.DumpStopContext(&ss, true);
|
2020-01-28 20:23:46 +01:00
|
|
|
watchpoint_sp->SetDeclInfo(std::string(ss.GetString()));
|
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
|
|
|
}
|
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
|
|
|
}
|
2013-03-27 23:08:40 +00:00
|
|
|
} else if (target_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
|
|
|
error.SetErrorStringWithFormat("could not get SBValue: %s",
|
2013-03-27 23:08:40 +00:00
|
|
|
locker.GetError().AsCString());
|
2013-05-15 02:16:21 +00:00
|
|
|
} else {
|
2013-03-27 23:08:40 +00:00
|
|
|
error.SetErrorString("could not set watchpoint, a target is required");
|
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
|
|
|
}
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2022-01-09 22:54:08 -08:00
|
|
|
return sb_watchpoint;
|
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
|
|
|
}
|
2011-10-13 18:08:26 +00:00
|
|
|
|
2013-05-15 02:16:21 +00:00
|
|
|
// FIXME: Remove this method impl (as well as the decl in .h) once it is no
|
2012-02-04 02:27:34 +00:00
|
|
|
// longer needed.
|
2012-06-04 23:45:50 +00:00
|
|
|
// Backward compatibility fix in the interim.
|
|
|
|
lldb::SBWatchpoint SBValue::Watch(bool resolve_location, bool read,
|
|
|
|
bool write) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, resolve_location, read, write);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2012-06-05 00:14:15 +00:00
|
|
|
SBError error;
|
2022-01-09 22:54:08 -08:00
|
|
|
return Watch(resolve_location, read, write, error);
|
2012-06-04 23:45:50 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-06-04 23:19:54 +00:00
|
|
|
lldb::SBWatchpoint SBValue::WatchPointee(bool resolve_location, bool read,
|
|
|
|
bool write, SBError &error) {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this, resolve_location, read, write, error);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2012-02-04 02:27:34 +00:00
|
|
|
SBWatchpoint sb_watchpoint;
|
|
|
|
if (IsInScope() && GetType().IsPointerType())
|
2012-06-04 23:19:54 +00:00
|
|
|
sb_watchpoint = Dereference().Watch(resolve_location, read, write, error);
|
2022-01-09 22:54:08 -08:00
|
|
|
return sb_watchpoint;
|
2011-10-13 18:08:26 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2014-12-08 23:13:56 +00:00
|
|
|
lldb::SBValue SBValue::Persist() {
|
2022-01-19 11:38:26 -08:00
|
|
|
LLDB_INSTRUMENT_VA(this);
|
2019-03-06 00:06:00 +00:00
|
|
|
|
2014-12-08 23:13:56 +00:00
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
|
|
|
SBValue persisted_sb;
|
|
|
|
if (value_sp) {
|
|
|
|
persisted_sb.SetSP(value_sp->Persist());
|
|
|
|
}
|
2022-01-09 22:54:08 -08:00
|
|
|
return persisted_sb;
|
2014-12-08 23:13:56 +00:00
|
|
|
}
|
2023-10-30 17:46:18 -07:00
|
|
|
|
|
|
|
lldb::SBValue SBValue::GetVTable() {
|
|
|
|
SBValue vtable_sb;
|
|
|
|
ValueLocker locker;
|
|
|
|
lldb::ValueObjectSP value_sp(GetSP(locker));
|
|
|
|
if (!value_sp)
|
|
|
|
return vtable_sb;
|
|
|
|
|
|
|
|
vtable_sb.SetSP(value_sp->GetVTable());
|
|
|
|
return vtable_sb;
|
|
|
|
}
|