[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
|
|
|
//===-- Watchpoint.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
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
2015-10-30 18:50:12 +00:00
|
|
|
#include "lldb/Breakpoint/Watchpoint.h"
|
|
|
|
|
|
2011-10-17 18:58:00 +00:00
|
|
|
#include "lldb/Breakpoint/StoppointCallbackContext.h"
|
[lldb] [mostly NFC] Large WP foundation: WatchpointResources (#68845)
This patch is rearranging code a bit to add WatchpointResources to
Process. A WatchpointResource is meant to represent a hardware
watchpoint register in the inferior process. It has an address, a size,
a type, and a list of Watchpoints that are using this
WatchpointResource.
This current patch doesn't add any of the features of
WatchpointResources that make them interesting -- a user asking to watch
a 24 byte object could watch this with three 8 byte WatchpointResources.
Or a Watchpoint on 1 byte at 0x1002 and a second watchpoint on 1 byte at
0x1003, these must both be served by a single WatchpointResource on that
doubleword at 0x1000 on a 64-bit target, if two hardware watchpoint
registers were used to track these separately, one of them may not be
hit. Or if you have one Watchpoint on a variable with a condition set,
and another Watchpoint on that same variable with a command defined or
different condition, or ignorecount, both of those Watchpoints need to
evaluate their criteria/commands when their WatchpointResource has been
hit.
There's a bit of code movement to rearrange things in the direction I'll
need for implementing this feature, so I want to start with reviewing &
landing this mostly NFC patch and we can focus on the algorithmic
choices about how WatchpointResources are shared and handled as they're
triggeed, separately.
This patch also stops printing "Watchpoint <n> hit: old value: <x>, new
vlaue: <y>" for Read watchpoints. I could make an argument for print
"Watchpoint <n> hit: current value <x>" but the current output doesn't
make any sense, and the user can print the value if they are
particularly interested. Read watchpoints are used primarily to
understand what code is reading a variable.
This patch adds more fallbacks for how to print the objects being
watched if we have types, instead of assuming they are all integral
values, so a struct will print its elements. As large watchpoints are
added, we'll be doing a lot more of those.
To track the WatchpointSP in the WatchpointResources, I changed the
internal API which took a WatchpointSP and devolved it to a Watchpoint*,
which meant touching several different Process files. I removed the
watchpoint code in ProcessKDP which only reported that watchpoints
aren't supported, the base class does that already.
I haven't yet changed how we receive a watchpoint to identify the
WatchpointResource responsible for the trigger, and identify all
Watchpoints that are using this Resource to evaluate their conditions
etc. This is the same work that a BreakpointSite needs to do when it has
been tiggered, where multiple Breakpoints may be at the same address.
There is not yet any printing of the Resources that a Watchpoint is
implemented in terms of ("watchpoint list", or
SBWatchpoint::GetDescription).
"watchpoint set var" and "watchpoint set expression" take a size
argument which was previously 1, 2, 4, or 8 (an enum). I've changed this
to an unsigned int. Most hardware implementations can only watch 1, 2,
4, 8 byte ranges, but with Resources we'll allow a user to ask for
different sized watchpoints and set them in hardware-expressble terms
soon.
I've annotated areas where I know there is work still needed with
LWP_TODO that I'll be working on once this is landed.
I've tested this on aarch64 macOS, aarch64 Linux, and Intel macOS.
https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116
(cherry picked from commit fc6b72523f3d73b921690a713e97a433c96066c6)
2023-11-27 13:28:59 -08:00
|
|
|
#include "lldb/Breakpoint/WatchpointResource.h"
|
2012-10-23 07:20:06 +00:00
|
|
|
#include "lldb/Core/Value.h"
|
[lldb] [mostly NFC] Large WP foundation: WatchpointResources (#68845)
This patch is rearranging code a bit to add WatchpointResources to
Process. A WatchpointResource is meant to represent a hardware
watchpoint register in the inferior process. It has an address, a size,
a type, and a list of Watchpoints that are using this
WatchpointResource.
This current patch doesn't add any of the features of
WatchpointResources that make them interesting -- a user asking to watch
a 24 byte object could watch this with three 8 byte WatchpointResources.
Or a Watchpoint on 1 byte at 0x1002 and a second watchpoint on 1 byte at
0x1003, these must both be served by a single WatchpointResource on that
doubleword at 0x1000 on a 64-bit target, if two hardware watchpoint
registers were used to track these separately, one of them may not be
hit. Or if you have one Watchpoint on a variable with a condition set,
and another Watchpoint on that same variable with a command defined or
different condition, or ignorecount, both of those Watchpoints need to
evaluate their criteria/commands when their WatchpointResource has been
hit.
There's a bit of code movement to rearrange things in the direction I'll
need for implementing this feature, so I want to start with reviewing &
landing this mostly NFC patch and we can focus on the algorithmic
choices about how WatchpointResources are shared and handled as they're
triggeed, separately.
This patch also stops printing "Watchpoint <n> hit: old value: <x>, new
vlaue: <y>" for Read watchpoints. I could make an argument for print
"Watchpoint <n> hit: current value <x>" but the current output doesn't
make any sense, and the user can print the value if they are
particularly interested. Read watchpoints are used primarily to
understand what code is reading a variable.
This patch adds more fallbacks for how to print the objects being
watched if we have types, instead of assuming they are all integral
values, so a struct will print its elements. As large watchpoints are
added, we'll be doing a lot more of those.
To track the WatchpointSP in the WatchpointResources, I changed the
internal API which took a WatchpointSP and devolved it to a Watchpoint*,
which meant touching several different Process files. I removed the
watchpoint code in ProcessKDP which only reported that watchpoints
aren't supported, the base class does that already.
I haven't yet changed how we receive a watchpoint to identify the
WatchpointResource responsible for the trigger, and identify all
Watchpoints that are using this Resource to evaluate their conditions
etc. This is the same work that a BreakpointSite needs to do when it has
been tiggered, where multiple Breakpoints may be at the same address.
There is not yet any printing of the Resources that a Watchpoint is
implemented in terms of ("watchpoint list", or
SBWatchpoint::GetDescription).
"watchpoint set var" and "watchpoint set expression" take a size
argument which was previously 1, 2, 4, or 8 (an enum). I've changed this
to an unsigned int. Most hardware implementations can only watch 1, 2,
4, 8 byte ranges, but with Resources we'll allow a user to ask for
different sized watchpoints and set them in hardware-expressble terms
soon.
I've annotated areas where I know there is work still needed with
LWP_TODO that I'll be working on once this is landed.
I've tested this on aarch64 macOS, aarch64 Linux, and Intel macOS.
https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116
(cherry picked from commit fc6b72523f3d73b921690a713e97a433c96066c6)
2023-11-27 13:28:59 -08:00
|
|
|
#include "lldb/DataFormatters/DumpValueObjectOptions.h"
|
2015-09-15 21:13:50 +00:00
|
|
|
#include "lldb/Expression/UserExpression.h"
|
2019-07-18 20:58:24 +00:00
|
|
|
#include "lldb/Symbol/TypeSystem.h"
|
2011-10-17 18:58:00 +00:00
|
|
|
#include "lldb/Target/Process.h"
|
|
|
|
|
#include "lldb/Target/Target.h"
|
|
|
|
|
#include "lldb/Target/ThreadSpec.h"
|
2022-02-03 13:26:10 +01:00
|
|
|
#include "lldb/Utility/LLDBLog.h"
|
2019-07-30 22:12:34 +00:00
|
|
|
#include "lldb/Utility/Log.h"
|
2017-02-02 21:39:50 +00:00
|
|
|
#include "lldb/Utility/Stream.h"
|
2024-10-24 20:20:48 -07:00
|
|
|
#include "lldb/ValueObject/ValueObject.h"
|
|
|
|
|
#include "lldb/ValueObject/ValueObjectMemory.h"
|
2010-06-08 16:52:24 +00:00
|
|
|
|
|
|
|
|
using namespace lldb;
|
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
|
2015-08-11 22:53:00 +00:00
|
|
|
Watchpoint::Watchpoint(Target &target, lldb::addr_t addr, uint32_t size,
|
|
|
|
|
const CompilerType *type, bool hardware)
|
2020-07-23 18:41:14 +03:00
|
|
|
: StoppointSite(0, addr, size, hardware), m_target(target),
|
2012-08-13 21:09:54 +00:00
|
|
|
m_enabled(false), m_is_hardware(hardware), m_is_watch_variable(false),
|
2012-08-21 23:17:04 +00:00
|
|
|
m_is_ephemeral(false), m_disabled_count(0), m_watch_read(0),
|
2024-01-31 14:44:52 -08:00
|
|
|
m_watch_write(0), m_watch_modify(0), m_ignore_count(0) {
|
2019-07-30 22:12:34 +00:00
|
|
|
|
2012-10-23 07:20:06 +00:00
|
|
|
if (type && type->IsValid())
|
|
|
|
|
m_type = *type;
|
|
|
|
|
else {
|
|
|
|
|
// If we don't have a known type, then we force it to unsigned int of the
|
|
|
|
|
// right size.
|
2019-07-30 22:12:34 +00:00
|
|
|
auto type_system_or_err =
|
|
|
|
|
target.GetScratchTypeSystemForLanguage(eLanguageTypeC);
|
|
|
|
|
if (auto err = type_system_or_err.takeError()) {
|
2022-01-31 15:57:48 +01:00
|
|
|
LLDB_LOG_ERROR(GetLog(LLDBLog::Watchpoints), std::move(err),
|
2023-07-05 10:47:14 -07:00
|
|
|
"Failed to set type: {0}");
|
2019-07-30 22:12:34 +00:00
|
|
|
} else {
|
[lldb] Add support for large watchpoints in lldb (#79962)
This patch is the next piece of work in my Large Watchpoint proposal,
https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116
This patch breaks a user's watchpoint into one or more
WatchpointResources which reflect what the hardware registers can cover.
This means we can watch objects larger than 8 bytes, and we can watched
unaligned address ranges. On a typical 64-bit target with 4 watchpoint
registers you can watch 32 bytes of memory if the start address is
doubleword aligned.
Additionally, if the remote stub implements AArch64 MASK style
watchpoints (e.g. debugserver on Darwin), we can watch any power-of-2
size region of memory up to 2GB, aligned to that same size.
I updated the Watchpoint constructor and CommandObjectWatchpoint to
create a CompilerType of Array<UInt8> when the size of the watched
region is greater than pointer-size and we don't have a variable type to
use. For pointer-size and smaller, we can display the watched granule as
an integer value; for larger-than-pointer-size we will display as an
array of bytes.
I have `watchpoint list` now print the WatchpointResources used to
implement the watchpoint.
I added a WatchpointAlgorithm class which has a top-level static method
that takes an enum flag mask WatchpointHardwareFeature and a user
address and size, and returns a vector of WatchpointResources covering
the request. It does not take into account the number of watchpoint
registers the target has, or the number still available for use. Right
now there is only one algorithm, which monitors power-of-2 regions of
memory. For up to pointer-size, this is what Intel hardware supports.
AArch64 Byte Address Select watchpoints can watch any number of
contiguous bytes in a pointer-size memory granule, that is not currently
supported so if you ask to watch bytes 3-5, the algorithm will watch the
entire doubleword (8 bytes). The newly default "modify" style means we
will silently ignore modifications to bytes outside the watched range.
I've temporarily skipped TestLargeWatchpoint.py for all targets. It was
only run on Darwin when using the in-tree debugserver, which was a proxy
for "debugserver supports MASK watchpoints". I'll be adding the
aforementioned feature flag from the stub and enabling full mask
watchpoints when a debugserver with that feature is enabled, and
re-enable this test.
I added a new TestUnalignedLargeWatchpoint.py which only has one test
but it's a great one, watching a 22-byte range that is unaligned and
requires four 8-byte watchpoints to cover.
I also added a unit test, WatchpointAlgorithmsTests, which has a number
of simple tests against WatchpointAlgorithms::PowerOf2Watchpoints. I
think there's interesting possible different approaches to how we cover
these; I note in the unit test that a user requesting a watch on address
0x12e0 of 120 bytes will be covered by two watchpoints today, a
128-bytes at 0x1280 and at 0x1300. But it could be done with a 16-byte
watchpoint at 0x12e0 and a 128-byte at 0x1300, which would have fewer
false positives/private stops. As we try refining this one, it's helpful
to have a collection of tests to make sure things don't regress.
I tested this on arm64 macOS, (genuine) x86_64 macOS, and AArch64
Ubuntu. I have not modifed the Windows process plugins yet, I might try
that as a standalone patch, I'd be making the change blind, but the
necessary changes (see ProcessGDBRemote::EnableWatchpoint) are pretty
small so it might be obvious enough that I can change it and see what
the Windows CI thinks.
There isn't yet a packet (or a qSupported feature query) for the gdb
remote serial protocol stub to communicate its watchpoint capabilities
to lldb. I'll be doing that in a patch right after this is landed,
having debugserver advertise its capability of AArch64 MASK watchpoints,
and have ProcessGDBRemote add eWatchpointHardwareArmMASK to
WatchpointAlgorithms so we can watch larger than 32-byte requests on
Darwin.
I haven't yet tackled WatchpointResource *sharing* by multiple
Watchpoints. This is all part of the goal, especially when we may be
watching a larger memory range than the user requested, if they then add
another watchpoint next to their first request, it may be covered by the
same WatchpointResource (hardware watchpoint register). Also one "read"
watchpoint and one "write" watchpoint on the same memory granule need to
be handled, making the WatchpointResource cover all requests.
As WatchpointResources aren't shared among multiple Watchpoints yet,
there's no handling of running the conditions/commands/etc on multiple
Watchpoints when their shared WatchpointResource is hit. The goal beyond
"large watchpoint" is to unify (much more) the Watchpoint and Breakpoint
behavior and commands. I have a feeling I may be slowly chipping away at
this for a while.
Re-landing this patch after fixing two undefined behaviors in
WatchpointAlgorithms found by UBSan and by failures on different
CI bots.
rdar://108234227
2024-01-31 21:01:59 -08:00
|
|
|
if (auto ts = *type_system_or_err) {
|
|
|
|
|
if (size <= target.GetArchitecture().GetAddressByteSize()) {
|
|
|
|
|
m_type =
|
|
|
|
|
ts->GetBuiltinTypeForEncodingAndBitSize(eEncodingUint, 8 * size);
|
|
|
|
|
} else {
|
|
|
|
|
CompilerType clang_uint8_type =
|
|
|
|
|
ts->GetBuiltinTypeForEncodingAndBitSize(eEncodingUint, 8);
|
|
|
|
|
m_type = clang_uint8_type.GetArrayType(size);
|
|
|
|
|
}
|
|
|
|
|
} else
|
2022-11-14 16:24:36 -08:00
|
|
|
LLDB_LOG_ERROR(GetLog(LLDBLog::Watchpoints), std::move(err),
|
2023-07-05 10:47:14 -07:00
|
|
|
"Failed to set type: Typesystem is no longer live: {0}");
|
2019-07-30 22:12:34 +00:00
|
|
|
}
|
2012-10-23 07:20:06 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-10-23 07:20:06 +00:00
|
|
|
// Set the initial value of the watched variable:
|
|
|
|
|
if (m_target.GetProcessSP()) {
|
|
|
|
|
ExecutionContext exe_ctx;
|
|
|
|
|
m_target.GetProcessSP()->CalculateExecutionContext(exe_ctx);
|
|
|
|
|
CaptureWatchedValue(exe_ctx);
|
|
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
2015-10-30 18:50:12 +00:00
|
|
|
Watchpoint::~Watchpoint() = default;
|
2010-06-08 16:52:24 +00:00
|
|
|
|
2012-08-09 23:09:42 +00:00
|
|
|
// This function is used when "baton" doesn't need to be freed
|
|
|
|
|
void Watchpoint::SetCallback(WatchpointHitCallback callback, void *baton,
|
|
|
|
|
bool is_synchronous) {
|
2018-04-30 16:49:04 +00:00
|
|
|
// The default "Baton" class will keep a copy of "baton" and won't free or
|
2023-09-01 21:32:24 -07:00
|
|
|
// delete it when it goes out of scope.
|
2016-09-13 17:53:38 +00:00
|
|
|
m_options.SetCallback(callback, std::make_shared<UntypedBaton>(baton),
|
|
|
|
|
is_synchronous);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-12-18 02:03:49 +00:00
|
|
|
SendWatchpointChangedEvent(eWatchpointEventTypeCommandChanged);
|
2012-08-09 23:09:42 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// This function is used when a baton needs to be freed and therefore is
|
|
|
|
|
// contained in a "Baton" subclass.
|
|
|
|
|
void Watchpoint::SetCallback(WatchpointHitCallback callback,
|
|
|
|
|
const BatonSP &callback_baton_sp,
|
|
|
|
|
bool is_synchronous) {
|
|
|
|
|
m_options.SetCallback(callback, callback_baton_sp, is_synchronous);
|
2012-12-18 02:03:49 +00:00
|
|
|
SendWatchpointChangedEvent(eWatchpointEventTypeCommandChanged);
|
2012-08-09 23:09:42 +00:00
|
|
|
}
|
|
|
|
|
|
2023-06-07 16:51:45 -07:00
|
|
|
bool Watchpoint::SetupVariableWatchpointDisabler(StackFrameSP frame_sp) const {
|
|
|
|
|
if (!frame_sp)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
ThreadSP thread_sp = frame_sp->GetThread();
|
|
|
|
|
if (!thread_sp)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
uint32_t return_frame_index =
|
|
|
|
|
thread_sp->GetSelectedFrameIndex(DoNoSelectMostRelevantFrame) + 1;
|
|
|
|
|
if (return_frame_index >= LLDB_INVALID_FRAME_ID)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
StackFrameSP return_frame_sp(
|
|
|
|
|
thread_sp->GetStackFrameAtIndex(return_frame_index));
|
|
|
|
|
if (!return_frame_sp)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
ExecutionContext exe_ctx(return_frame_sp);
|
|
|
|
|
TargetSP target_sp = exe_ctx.GetTargetSP();
|
|
|
|
|
if (!target_sp)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
Address return_address(return_frame_sp->GetFrameCodeAddress());
|
|
|
|
|
lldb::addr_t return_addr = return_address.GetLoadAddress(target_sp.get());
|
|
|
|
|
if (return_addr == LLDB_INVALID_ADDRESS)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
BreakpointSP bp_sp = target_sp->CreateBreakpoint(
|
|
|
|
|
return_addr, /*internal=*/true, /*request_hardware=*/false);
|
|
|
|
|
if (!bp_sp || !bp_sp->HasResolvedLocations())
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
auto wvc_up = std::make_unique<WatchpointVariableContext>(GetID(), exe_ctx);
|
|
|
|
|
auto baton_sp = std::make_shared<WatchpointVariableBaton>(std::move(wvc_up));
|
|
|
|
|
bp_sp->SetCallback(VariableWatchpointDisabler, baton_sp);
|
|
|
|
|
bp_sp->SetOneShot(true);
|
|
|
|
|
bp_sp->SetBreakpointKind("variable watchpoint disabler");
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool Watchpoint::VariableWatchpointDisabler(void *baton,
|
|
|
|
|
StoppointCallbackContext *context,
|
|
|
|
|
user_id_t break_id,
|
|
|
|
|
user_id_t break_loc_id) {
|
|
|
|
|
assert(baton && "null baton");
|
|
|
|
|
if (!baton || !context)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
Log *log = GetLog(LLDBLog::Watchpoints);
|
|
|
|
|
|
|
|
|
|
WatchpointVariableContext *wvc =
|
|
|
|
|
static_cast<WatchpointVariableContext *>(baton);
|
|
|
|
|
|
|
|
|
|
LLDB_LOGF(log, "called by breakpoint %" PRIu64 ".%" PRIu64, break_id,
|
|
|
|
|
break_loc_id);
|
|
|
|
|
|
|
|
|
|
if (wvc->watch_id == LLDB_INVALID_WATCH_ID)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
TargetSP target_sp = context->exe_ctx_ref.GetTargetSP();
|
|
|
|
|
if (!target_sp)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
ProcessSP process_sp = target_sp->GetProcessSP();
|
|
|
|
|
if (!process_sp)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
WatchpointSP watch_sp =
|
|
|
|
|
target_sp->GetWatchpointList().FindByID(wvc->watch_id);
|
|
|
|
|
if (!watch_sp)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
if (wvc->exe_ctx == context->exe_ctx_ref) {
|
|
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"callback for watchpoint %" PRId32
|
|
|
|
|
" matched internal breakpoint execution context",
|
|
|
|
|
watch_sp->GetID());
|
[lldb] [mostly NFC] Large WP foundation: WatchpointResources (#68845)
This patch is rearranging code a bit to add WatchpointResources to
Process. A WatchpointResource is meant to represent a hardware
watchpoint register in the inferior process. It has an address, a size,
a type, and a list of Watchpoints that are using this
WatchpointResource.
This current patch doesn't add any of the features of
WatchpointResources that make them interesting -- a user asking to watch
a 24 byte object could watch this with three 8 byte WatchpointResources.
Or a Watchpoint on 1 byte at 0x1002 and a second watchpoint on 1 byte at
0x1003, these must both be served by a single WatchpointResource on that
doubleword at 0x1000 on a 64-bit target, if two hardware watchpoint
registers were used to track these separately, one of them may not be
hit. Or if you have one Watchpoint on a variable with a condition set,
and another Watchpoint on that same variable with a command defined or
different condition, or ignorecount, both of those Watchpoints need to
evaluate their criteria/commands when their WatchpointResource has been
hit.
There's a bit of code movement to rearrange things in the direction I'll
need for implementing this feature, so I want to start with reviewing &
landing this mostly NFC patch and we can focus on the algorithmic
choices about how WatchpointResources are shared and handled as they're
triggeed, separately.
This patch also stops printing "Watchpoint <n> hit: old value: <x>, new
vlaue: <y>" for Read watchpoints. I could make an argument for print
"Watchpoint <n> hit: current value <x>" but the current output doesn't
make any sense, and the user can print the value if they are
particularly interested. Read watchpoints are used primarily to
understand what code is reading a variable.
This patch adds more fallbacks for how to print the objects being
watched if we have types, instead of assuming they are all integral
values, so a struct will print its elements. As large watchpoints are
added, we'll be doing a lot more of those.
To track the WatchpointSP in the WatchpointResources, I changed the
internal API which took a WatchpointSP and devolved it to a Watchpoint*,
which meant touching several different Process files. I removed the
watchpoint code in ProcessKDP which only reported that watchpoints
aren't supported, the base class does that already.
I haven't yet changed how we receive a watchpoint to identify the
WatchpointResource responsible for the trigger, and identify all
Watchpoints that are using this Resource to evaluate their conditions
etc. This is the same work that a BreakpointSite needs to do when it has
been tiggered, where multiple Breakpoints may be at the same address.
There is not yet any printing of the Resources that a Watchpoint is
implemented in terms of ("watchpoint list", or
SBWatchpoint::GetDescription).
"watchpoint set var" and "watchpoint set expression" take a size
argument which was previously 1, 2, 4, or 8 (an enum). I've changed this
to an unsigned int. Most hardware implementations can only watch 1, 2,
4, 8 byte ranges, but with Resources we'll allow a user to ask for
different sized watchpoints and set them in hardware-expressble terms
soon.
I've annotated areas where I know there is work still needed with
LWP_TODO that I'll be working on once this is landed.
I've tested this on aarch64 macOS, aarch64 Linux, and Intel macOS.
https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116
(cherry picked from commit fc6b72523f3d73b921690a713e97a433c96066c6)
2023-11-27 13:28:59 -08:00
|
|
|
process_sp->DisableWatchpoint(watch_sp);
|
2023-06-07 16:51:45 -07:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"callback for watchpoint %" PRId32
|
|
|
|
|
" didn't match internal breakpoint execution context",
|
|
|
|
|
watch_sp->GetID());
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2012-08-09 23:09:42 +00:00
|
|
|
void Watchpoint::ClearCallback() {
|
|
|
|
|
m_options.ClearCallback();
|
2012-12-18 02:03:49 +00:00
|
|
|
SendWatchpointChangedEvent(eWatchpointEventTypeCommandChanged);
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
2012-08-13 21:09:54 +00:00
|
|
|
void Watchpoint::SetDeclInfo(const std::string &str) { m_decl_str = str; }
|
2011-09-16 21:41:42 +00:00
|
|
|
|
2012-08-13 21:09:54 +00:00
|
|
|
std::string Watchpoint::GetWatchSpec() { return m_watch_spec_str; }
|
|
|
|
|
|
|
|
|
|
void Watchpoint::SetWatchSpec(const std::string &str) {
|
2012-02-25 06:44:30 +00:00
|
|
|
m_watch_spec_str = str;
|
|
|
|
|
}
|
|
|
|
|
|
2020-07-21 21:04:36 +03:00
|
|
|
bool Watchpoint::IsHardware() const {
|
|
|
|
|
lldbassert(m_is_hardware || !HardwareRequired());
|
|
|
|
|
return m_is_hardware;
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-08-13 21:09:54 +00:00
|
|
|
bool Watchpoint::IsWatchVariable() const { return m_is_watch_variable; }
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-08-13 21:09:54 +00:00
|
|
|
void Watchpoint::SetWatchVariable(bool val) { m_is_watch_variable = val; }
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-10-23 07:20:06 +00:00
|
|
|
bool Watchpoint::CaptureWatchedValue(const ExecutionContext &exe_ctx) {
|
2023-09-21 10:21:53 +00:00
|
|
|
ConstString g_watch_name("$__lldb__watch_value");
|
2012-10-23 07:20:06 +00:00
|
|
|
m_old_value_sp = m_new_value_sp;
|
|
|
|
|
Address watch_address(GetLoadAddress());
|
2012-10-23 21:09:09 +00:00
|
|
|
if (!m_type.IsValid()) {
|
|
|
|
|
// Don't know how to report new & old values, since we couldn't make a
|
2018-04-30 16:49:04 +00:00
|
|
|
// scalar type for this watchpoint. This works around an assert in
|
|
|
|
|
// ValueObjectMemory::Create.
|
2012-10-23 21:09:09 +00:00
|
|
|
// FIXME: This should not happen, but if it does in some case we care about,
|
|
|
|
|
// we can go grab the value raw and print it as unsigned.
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2016-11-12 18:17:36 +00:00
|
|
|
m_new_value_sp = ValueObjectMemory::Create(
|
2023-09-21 10:21:53 +00:00
|
|
|
exe_ctx.GetBestExecutionContextScope(), g_watch_name.GetStringRef(),
|
2016-11-12 18:17:36 +00:00
|
|
|
watch_address, m_type);
|
2023-09-21 10:21:53 +00:00
|
|
|
m_new_value_sp = m_new_value_sp->CreateConstantValue(g_watch_name);
|
2015-10-30 18:50:12 +00:00
|
|
|
return (m_new_value_sp && m_new_value_sp->GetError().Success());
|
2012-10-23 07:20:06 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2023-09-21 10:21:53 +00:00
|
|
|
bool Watchpoint::WatchedValueReportable(const ExecutionContext &exe_ctx) {
|
|
|
|
|
if (!m_watch_modify || m_watch_read)
|
|
|
|
|
return true;
|
|
|
|
|
if (!m_type.IsValid())
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
ConstString g_watch_name("$__lldb__watch_value");
|
|
|
|
|
Address watch_address(GetLoadAddress());
|
|
|
|
|
ValueObjectSP newest_valueobj_sp = ValueObjectMemory::Create(
|
|
|
|
|
exe_ctx.GetBestExecutionContextScope(), g_watch_name.GetStringRef(),
|
|
|
|
|
watch_address, m_type);
|
|
|
|
|
newest_valueobj_sp = newest_valueobj_sp->CreateConstantValue(g_watch_name);
|
|
|
|
|
Status error;
|
|
|
|
|
|
|
|
|
|
DataExtractor new_data;
|
|
|
|
|
DataExtractor old_data;
|
|
|
|
|
|
|
|
|
|
newest_valueobj_sp->GetData(new_data, error);
|
|
|
|
|
if (error.Fail())
|
|
|
|
|
return true;
|
|
|
|
|
m_new_value_sp->GetData(old_data, error);
|
|
|
|
|
if (error.Fail())
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
if (new_data.GetByteSize() != old_data.GetByteSize() ||
|
|
|
|
|
new_data.GetByteSize() == 0)
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
if (memcmp(new_data.GetDataStart(), old_data.GetDataStart(),
|
|
|
|
|
old_data.GetByteSize()) == 0)
|
|
|
|
|
return false; // Value has not changed, user requested modify watchpoint
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
// RETURNS - true if we should stop at this breakpoint, false if we
|
|
|
|
|
// should continue.
|
|
|
|
|
|
2011-10-14 00:42:25 +00:00
|
|
|
bool Watchpoint::ShouldStop(StoppointCallbackContext *context) {
|
2020-07-23 18:41:14 +03:00
|
|
|
m_hit_counter.Increment();
|
2011-09-22 18:04:58 +00:00
|
|
|
|
2018-12-15 00:15:33 +00:00
|
|
|
return IsEnabled();
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
2011-10-14 00:42:25 +00:00
|
|
|
void Watchpoint::GetDescription(Stream *s, lldb::DescriptionLevel level) {
|
2011-09-16 21:41:42 +00:00
|
|
|
DumpWithLevel(s, level);
|
2011-09-12 23:38:44 +00:00
|
|
|
}
|
|
|
|
|
|
2011-10-14 00:42:25 +00:00
|
|
|
void Watchpoint::Dump(Stream *s) const {
|
2011-09-16 21:41:42 +00:00
|
|
|
DumpWithLevel(s, lldb::eDescriptionLevelBrief);
|
|
|
|
|
}
|
|
|
|
|
|
2015-10-30 18:50:12 +00:00
|
|
|
// If prefix is nullptr, we display the watch id and ignore the prefix
|
|
|
|
|
// altogether.
|
[lldb] [mostly NFC] Large WP foundation: WatchpointResources (#68845)
This patch is rearranging code a bit to add WatchpointResources to
Process. A WatchpointResource is meant to represent a hardware
watchpoint register in the inferior process. It has an address, a size,
a type, and a list of Watchpoints that are using this
WatchpointResource.
This current patch doesn't add any of the features of
WatchpointResources that make them interesting -- a user asking to watch
a 24 byte object could watch this with three 8 byte WatchpointResources.
Or a Watchpoint on 1 byte at 0x1002 and a second watchpoint on 1 byte at
0x1003, these must both be served by a single WatchpointResource on that
doubleword at 0x1000 on a 64-bit target, if two hardware watchpoint
registers were used to track these separately, one of them may not be
hit. Or if you have one Watchpoint on a variable with a condition set,
and another Watchpoint on that same variable with a command defined or
different condition, or ignorecount, both of those Watchpoints need to
evaluate their criteria/commands when their WatchpointResource has been
hit.
There's a bit of code movement to rearrange things in the direction I'll
need for implementing this feature, so I want to start with reviewing &
landing this mostly NFC patch and we can focus on the algorithmic
choices about how WatchpointResources are shared and handled as they're
triggeed, separately.
This patch also stops printing "Watchpoint <n> hit: old value: <x>, new
vlaue: <y>" for Read watchpoints. I could make an argument for print
"Watchpoint <n> hit: current value <x>" but the current output doesn't
make any sense, and the user can print the value if they are
particularly interested. Read watchpoints are used primarily to
understand what code is reading a variable.
This patch adds more fallbacks for how to print the objects being
watched if we have types, instead of assuming they are all integral
values, so a struct will print its elements. As large watchpoints are
added, we'll be doing a lot more of those.
To track the WatchpointSP in the WatchpointResources, I changed the
internal API which took a WatchpointSP and devolved it to a Watchpoint*,
which meant touching several different Process files. I removed the
watchpoint code in ProcessKDP which only reported that watchpoints
aren't supported, the base class does that already.
I haven't yet changed how we receive a watchpoint to identify the
WatchpointResource responsible for the trigger, and identify all
Watchpoints that are using this Resource to evaluate their conditions
etc. This is the same work that a BreakpointSite needs to do when it has
been tiggered, where multiple Breakpoints may be at the same address.
There is not yet any printing of the Resources that a Watchpoint is
implemented in terms of ("watchpoint list", or
SBWatchpoint::GetDescription).
"watchpoint set var" and "watchpoint set expression" take a size
argument which was previously 1, 2, 4, or 8 (an enum). I've changed this
to an unsigned int. Most hardware implementations can only watch 1, 2,
4, 8 byte ranges, but with Resources we'll allow a user to ask for
different sized watchpoints and set them in hardware-expressble terms
soon.
I've annotated areas where I know there is work still needed with
LWP_TODO that I'll be working on once this is landed.
I've tested this on aarch64 macOS, aarch64 Linux, and Intel macOS.
https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116
(cherry picked from commit fc6b72523f3d73b921690a713e97a433c96066c6)
2023-11-27 13:28:59 -08:00
|
|
|
bool Watchpoint::DumpSnapshots(Stream *s, const char *prefix) const {
|
|
|
|
|
bool printed_anything = false;
|
|
|
|
|
|
|
|
|
|
// For read watchpoints, don't display any before/after value changes.
|
|
|
|
|
if (m_watch_read && !m_watch_modify && !m_watch_write)
|
|
|
|
|
return printed_anything;
|
|
|
|
|
|
|
|
|
|
s->Printf("\n");
|
|
|
|
|
s->Printf("Watchpoint %u hit:\n", GetID());
|
|
|
|
|
|
|
|
|
|
StreamString values_ss;
|
|
|
|
|
if (prefix)
|
|
|
|
|
values_ss.Indent(prefix);
|
2015-10-09 15:13:20 +00:00
|
|
|
|
2012-10-23 07:20:06 +00:00
|
|
|
if (m_old_value_sp) {
|
[lldb] [mostly NFC] Large WP foundation: WatchpointResources (#68845)
This patch is rearranging code a bit to add WatchpointResources to
Process. A WatchpointResource is meant to represent a hardware
watchpoint register in the inferior process. It has an address, a size,
a type, and a list of Watchpoints that are using this
WatchpointResource.
This current patch doesn't add any of the features of
WatchpointResources that make them interesting -- a user asking to watch
a 24 byte object could watch this with three 8 byte WatchpointResources.
Or a Watchpoint on 1 byte at 0x1002 and a second watchpoint on 1 byte at
0x1003, these must both be served by a single WatchpointResource on that
doubleword at 0x1000 on a 64-bit target, if two hardware watchpoint
registers were used to track these separately, one of them may not be
hit. Or if you have one Watchpoint on a variable with a condition set,
and another Watchpoint on that same variable with a command defined or
different condition, or ignorecount, both of those Watchpoints need to
evaluate their criteria/commands when their WatchpointResource has been
hit.
There's a bit of code movement to rearrange things in the direction I'll
need for implementing this feature, so I want to start with reviewing &
landing this mostly NFC patch and we can focus on the algorithmic
choices about how WatchpointResources are shared and handled as they're
triggeed, separately.
This patch also stops printing "Watchpoint <n> hit: old value: <x>, new
vlaue: <y>" for Read watchpoints. I could make an argument for print
"Watchpoint <n> hit: current value <x>" but the current output doesn't
make any sense, and the user can print the value if they are
particularly interested. Read watchpoints are used primarily to
understand what code is reading a variable.
This patch adds more fallbacks for how to print the objects being
watched if we have types, instead of assuming they are all integral
values, so a struct will print its elements. As large watchpoints are
added, we'll be doing a lot more of those.
To track the WatchpointSP in the WatchpointResources, I changed the
internal API which took a WatchpointSP and devolved it to a Watchpoint*,
which meant touching several different Process files. I removed the
watchpoint code in ProcessKDP which only reported that watchpoints
aren't supported, the base class does that already.
I haven't yet changed how we receive a watchpoint to identify the
WatchpointResource responsible for the trigger, and identify all
Watchpoints that are using this Resource to evaluate their conditions
etc. This is the same work that a BreakpointSite needs to do when it has
been tiggered, where multiple Breakpoints may be at the same address.
There is not yet any printing of the Resources that a Watchpoint is
implemented in terms of ("watchpoint list", or
SBWatchpoint::GetDescription).
"watchpoint set var" and "watchpoint set expression" take a size
argument which was previously 1, 2, 4, or 8 (an enum). I've changed this
to an unsigned int. Most hardware implementations can only watch 1, 2,
4, 8 byte ranges, but with Resources we'll allow a user to ask for
different sized watchpoints and set them in hardware-expressble terms
soon.
I've annotated areas where I know there is work still needed with
LWP_TODO that I'll be working on once this is landed.
I've tested this on aarch64 macOS, aarch64 Linux, and Intel macOS.
https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116
(cherry picked from commit fc6b72523f3d73b921690a713e97a433c96066c6)
2023-11-27 13:28:59 -08:00
|
|
|
if (auto *old_value_cstr = m_old_value_sp->GetValueAsCString()) {
|
|
|
|
|
values_ss.Printf("old value: %s", old_value_cstr);
|
|
|
|
|
} else {
|
|
|
|
|
if (auto *old_summary_cstr = m_old_value_sp->GetSummaryAsCString())
|
|
|
|
|
values_ss.Printf("old value: %s", old_summary_cstr);
|
|
|
|
|
else {
|
|
|
|
|
StreamString strm;
|
|
|
|
|
DumpValueObjectOptions options;
|
|
|
|
|
options.SetUseDynamicType(eNoDynamicValues)
|
|
|
|
|
.SetHideRootType(true)
|
|
|
|
|
.SetHideRootName(true)
|
|
|
|
|
.SetHideName(true);
|
2024-06-17 14:29:01 -07:00
|
|
|
if (llvm::Error error = m_old_value_sp->Dump(strm, options))
|
|
|
|
|
strm << "error: " << toString(std::move(error));
|
|
|
|
|
|
[lldb] [mostly NFC] Large WP foundation: WatchpointResources (#68845)
This patch is rearranging code a bit to add WatchpointResources to
Process. A WatchpointResource is meant to represent a hardware
watchpoint register in the inferior process. It has an address, a size,
a type, and a list of Watchpoints that are using this
WatchpointResource.
This current patch doesn't add any of the features of
WatchpointResources that make them interesting -- a user asking to watch
a 24 byte object could watch this with three 8 byte WatchpointResources.
Or a Watchpoint on 1 byte at 0x1002 and a second watchpoint on 1 byte at
0x1003, these must both be served by a single WatchpointResource on that
doubleword at 0x1000 on a 64-bit target, if two hardware watchpoint
registers were used to track these separately, one of them may not be
hit. Or if you have one Watchpoint on a variable with a condition set,
and another Watchpoint on that same variable with a command defined or
different condition, or ignorecount, both of those Watchpoints need to
evaluate their criteria/commands when their WatchpointResource has been
hit.
There's a bit of code movement to rearrange things in the direction I'll
need for implementing this feature, so I want to start with reviewing &
landing this mostly NFC patch and we can focus on the algorithmic
choices about how WatchpointResources are shared and handled as they're
triggeed, separately.
This patch also stops printing "Watchpoint <n> hit: old value: <x>, new
vlaue: <y>" for Read watchpoints. I could make an argument for print
"Watchpoint <n> hit: current value <x>" but the current output doesn't
make any sense, and the user can print the value if they are
particularly interested. Read watchpoints are used primarily to
understand what code is reading a variable.
This patch adds more fallbacks for how to print the objects being
watched if we have types, instead of assuming they are all integral
values, so a struct will print its elements. As large watchpoints are
added, we'll be doing a lot more of those.
To track the WatchpointSP in the WatchpointResources, I changed the
internal API which took a WatchpointSP and devolved it to a Watchpoint*,
which meant touching several different Process files. I removed the
watchpoint code in ProcessKDP which only reported that watchpoints
aren't supported, the base class does that already.
I haven't yet changed how we receive a watchpoint to identify the
WatchpointResource responsible for the trigger, and identify all
Watchpoints that are using this Resource to evaluate their conditions
etc. This is the same work that a BreakpointSite needs to do when it has
been tiggered, where multiple Breakpoints may be at the same address.
There is not yet any printing of the Resources that a Watchpoint is
implemented in terms of ("watchpoint list", or
SBWatchpoint::GetDescription).
"watchpoint set var" and "watchpoint set expression" take a size
argument which was previously 1, 2, 4, or 8 (an enum). I've changed this
to an unsigned int. Most hardware implementations can only watch 1, 2,
4, 8 byte ranges, but with Resources we'll allow a user to ask for
different sized watchpoints and set them in hardware-expressble terms
soon.
I've annotated areas where I know there is work still needed with
LWP_TODO that I'll be working on once this is landed.
I've tested this on aarch64 macOS, aarch64 Linux, and Intel macOS.
https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116
(cherry picked from commit fc6b72523f3d73b921690a713e97a433c96066c6)
2023-11-27 13:28:59 -08:00
|
|
|
if (strm.GetData())
|
|
|
|
|
values_ss.Printf("old value: %s", strm.GetData());
|
|
|
|
|
}
|
2012-08-13 21:09:54 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2012-10-23 07:20:06 +00:00
|
|
|
if (m_new_value_sp) {
|
[lldb] [mostly NFC] Large WP foundation: WatchpointResources (#68845)
This patch is rearranging code a bit to add WatchpointResources to
Process. A WatchpointResource is meant to represent a hardware
watchpoint register in the inferior process. It has an address, a size,
a type, and a list of Watchpoints that are using this
WatchpointResource.
This current patch doesn't add any of the features of
WatchpointResources that make them interesting -- a user asking to watch
a 24 byte object could watch this with three 8 byte WatchpointResources.
Or a Watchpoint on 1 byte at 0x1002 and a second watchpoint on 1 byte at
0x1003, these must both be served by a single WatchpointResource on that
doubleword at 0x1000 on a 64-bit target, if two hardware watchpoint
registers were used to track these separately, one of them may not be
hit. Or if you have one Watchpoint on a variable with a condition set,
and another Watchpoint on that same variable with a command defined or
different condition, or ignorecount, both of those Watchpoints need to
evaluate their criteria/commands when their WatchpointResource has been
hit.
There's a bit of code movement to rearrange things in the direction I'll
need for implementing this feature, so I want to start with reviewing &
landing this mostly NFC patch and we can focus on the algorithmic
choices about how WatchpointResources are shared and handled as they're
triggeed, separately.
This patch also stops printing "Watchpoint <n> hit: old value: <x>, new
vlaue: <y>" for Read watchpoints. I could make an argument for print
"Watchpoint <n> hit: current value <x>" but the current output doesn't
make any sense, and the user can print the value if they are
particularly interested. Read watchpoints are used primarily to
understand what code is reading a variable.
This patch adds more fallbacks for how to print the objects being
watched if we have types, instead of assuming they are all integral
values, so a struct will print its elements. As large watchpoints are
added, we'll be doing a lot more of those.
To track the WatchpointSP in the WatchpointResources, I changed the
internal API which took a WatchpointSP and devolved it to a Watchpoint*,
which meant touching several different Process files. I removed the
watchpoint code in ProcessKDP which only reported that watchpoints
aren't supported, the base class does that already.
I haven't yet changed how we receive a watchpoint to identify the
WatchpointResource responsible for the trigger, and identify all
Watchpoints that are using this Resource to evaluate their conditions
etc. This is the same work that a BreakpointSite needs to do when it has
been tiggered, where multiple Breakpoints may be at the same address.
There is not yet any printing of the Resources that a Watchpoint is
implemented in terms of ("watchpoint list", or
SBWatchpoint::GetDescription).
"watchpoint set var" and "watchpoint set expression" take a size
argument which was previously 1, 2, 4, or 8 (an enum). I've changed this
to an unsigned int. Most hardware implementations can only watch 1, 2,
4, 8 byte ranges, but with Resources we'll allow a user to ask for
different sized watchpoints and set them in hardware-expressble terms
soon.
I've annotated areas where I know there is work still needed with
LWP_TODO that I'll be working on once this is landed.
I've tested this on aarch64 macOS, aarch64 Linux, and Intel macOS.
https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116
(cherry picked from commit fc6b72523f3d73b921690a713e97a433c96066c6)
2023-11-27 13:28:59 -08:00
|
|
|
if (values_ss.GetSize())
|
|
|
|
|
values_ss.Printf("\n");
|
|
|
|
|
|
|
|
|
|
if (auto *new_value_cstr = m_new_value_sp->GetValueAsCString())
|
|
|
|
|
values_ss.Printf("new value: %s", new_value_cstr);
|
2015-10-09 15:13:20 +00:00
|
|
|
else {
|
[lldb] [mostly NFC] Large WP foundation: WatchpointResources (#68845)
This patch is rearranging code a bit to add WatchpointResources to
Process. A WatchpointResource is meant to represent a hardware
watchpoint register in the inferior process. It has an address, a size,
a type, and a list of Watchpoints that are using this
WatchpointResource.
This current patch doesn't add any of the features of
WatchpointResources that make them interesting -- a user asking to watch
a 24 byte object could watch this with three 8 byte WatchpointResources.
Or a Watchpoint on 1 byte at 0x1002 and a second watchpoint on 1 byte at
0x1003, these must both be served by a single WatchpointResource on that
doubleword at 0x1000 on a 64-bit target, if two hardware watchpoint
registers were used to track these separately, one of them may not be
hit. Or if you have one Watchpoint on a variable with a condition set,
and another Watchpoint on that same variable with a command defined or
different condition, or ignorecount, both of those Watchpoints need to
evaluate their criteria/commands when their WatchpointResource has been
hit.
There's a bit of code movement to rearrange things in the direction I'll
need for implementing this feature, so I want to start with reviewing &
landing this mostly NFC patch and we can focus on the algorithmic
choices about how WatchpointResources are shared and handled as they're
triggeed, separately.
This patch also stops printing "Watchpoint <n> hit: old value: <x>, new
vlaue: <y>" for Read watchpoints. I could make an argument for print
"Watchpoint <n> hit: current value <x>" but the current output doesn't
make any sense, and the user can print the value if they are
particularly interested. Read watchpoints are used primarily to
understand what code is reading a variable.
This patch adds more fallbacks for how to print the objects being
watched if we have types, instead of assuming they are all integral
values, so a struct will print its elements. As large watchpoints are
added, we'll be doing a lot more of those.
To track the WatchpointSP in the WatchpointResources, I changed the
internal API which took a WatchpointSP and devolved it to a Watchpoint*,
which meant touching several different Process files. I removed the
watchpoint code in ProcessKDP which only reported that watchpoints
aren't supported, the base class does that already.
I haven't yet changed how we receive a watchpoint to identify the
WatchpointResource responsible for the trigger, and identify all
Watchpoints that are using this Resource to evaluate their conditions
etc. This is the same work that a BreakpointSite needs to do when it has
been tiggered, where multiple Breakpoints may be at the same address.
There is not yet any printing of the Resources that a Watchpoint is
implemented in terms of ("watchpoint list", or
SBWatchpoint::GetDescription).
"watchpoint set var" and "watchpoint set expression" take a size
argument which was previously 1, 2, 4, or 8 (an enum). I've changed this
to an unsigned int. Most hardware implementations can only watch 1, 2,
4, 8 byte ranges, but with Resources we'll allow a user to ask for
different sized watchpoints and set them in hardware-expressble terms
soon.
I've annotated areas where I know there is work still needed with
LWP_TODO that I'll be working on once this is landed.
I've tested this on aarch64 macOS, aarch64 Linux, and Intel macOS.
https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116
(cherry picked from commit fc6b72523f3d73b921690a713e97a433c96066c6)
2023-11-27 13:28:59 -08:00
|
|
|
if (auto *new_summary_cstr = m_new_value_sp->GetSummaryAsCString())
|
|
|
|
|
values_ss.Printf("new value: %s", new_summary_cstr);
|
|
|
|
|
else {
|
|
|
|
|
StreamString strm;
|
|
|
|
|
DumpValueObjectOptions options;
|
|
|
|
|
options.SetUseDynamicType(eNoDynamicValues)
|
|
|
|
|
.SetHideRootType(true)
|
|
|
|
|
.SetHideRootName(true)
|
|
|
|
|
.SetHideName(true);
|
2024-06-17 14:29:01 -07:00
|
|
|
if (llvm::Error error = m_new_value_sp->Dump(strm, options))
|
|
|
|
|
strm << "error: " << toString(std::move(error));
|
|
|
|
|
|
[lldb] [mostly NFC] Large WP foundation: WatchpointResources (#68845)
This patch is rearranging code a bit to add WatchpointResources to
Process. A WatchpointResource is meant to represent a hardware
watchpoint register in the inferior process. It has an address, a size,
a type, and a list of Watchpoints that are using this
WatchpointResource.
This current patch doesn't add any of the features of
WatchpointResources that make them interesting -- a user asking to watch
a 24 byte object could watch this with three 8 byte WatchpointResources.
Or a Watchpoint on 1 byte at 0x1002 and a second watchpoint on 1 byte at
0x1003, these must both be served by a single WatchpointResource on that
doubleword at 0x1000 on a 64-bit target, if two hardware watchpoint
registers were used to track these separately, one of them may not be
hit. Or if you have one Watchpoint on a variable with a condition set,
and another Watchpoint on that same variable with a command defined or
different condition, or ignorecount, both of those Watchpoints need to
evaluate their criteria/commands when their WatchpointResource has been
hit.
There's a bit of code movement to rearrange things in the direction I'll
need for implementing this feature, so I want to start with reviewing &
landing this mostly NFC patch and we can focus on the algorithmic
choices about how WatchpointResources are shared and handled as they're
triggeed, separately.
This patch also stops printing "Watchpoint <n> hit: old value: <x>, new
vlaue: <y>" for Read watchpoints. I could make an argument for print
"Watchpoint <n> hit: current value <x>" but the current output doesn't
make any sense, and the user can print the value if they are
particularly interested. Read watchpoints are used primarily to
understand what code is reading a variable.
This patch adds more fallbacks for how to print the objects being
watched if we have types, instead of assuming they are all integral
values, so a struct will print its elements. As large watchpoints are
added, we'll be doing a lot more of those.
To track the WatchpointSP in the WatchpointResources, I changed the
internal API which took a WatchpointSP and devolved it to a Watchpoint*,
which meant touching several different Process files. I removed the
watchpoint code in ProcessKDP which only reported that watchpoints
aren't supported, the base class does that already.
I haven't yet changed how we receive a watchpoint to identify the
WatchpointResource responsible for the trigger, and identify all
Watchpoints that are using this Resource to evaluate their conditions
etc. This is the same work that a BreakpointSite needs to do when it has
been tiggered, where multiple Breakpoints may be at the same address.
There is not yet any printing of the Resources that a Watchpoint is
implemented in terms of ("watchpoint list", or
SBWatchpoint::GetDescription).
"watchpoint set var" and "watchpoint set expression" take a size
argument which was previously 1, 2, 4, or 8 (an enum). I've changed this
to an unsigned int. Most hardware implementations can only watch 1, 2,
4, 8 byte ranges, but with Resources we'll allow a user to ask for
different sized watchpoints and set them in hardware-expressble terms
soon.
I've annotated areas where I know there is work still needed with
LWP_TODO that I'll be working on once this is landed.
I've tested this on aarch64 macOS, aarch64 Linux, and Intel macOS.
https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116
(cherry picked from commit fc6b72523f3d73b921690a713e97a433c96066c6)
2023-11-27 13:28:59 -08:00
|
|
|
if (strm.GetData())
|
|
|
|
|
values_ss.Printf("new value: %s", strm.GetData());
|
|
|
|
|
}
|
2012-08-13 21:09:54 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
[lldb] [mostly NFC] Large WP foundation: WatchpointResources (#68845)
This patch is rearranging code a bit to add WatchpointResources to
Process. A WatchpointResource is meant to represent a hardware
watchpoint register in the inferior process. It has an address, a size,
a type, and a list of Watchpoints that are using this
WatchpointResource.
This current patch doesn't add any of the features of
WatchpointResources that make them interesting -- a user asking to watch
a 24 byte object could watch this with three 8 byte WatchpointResources.
Or a Watchpoint on 1 byte at 0x1002 and a second watchpoint on 1 byte at
0x1003, these must both be served by a single WatchpointResource on that
doubleword at 0x1000 on a 64-bit target, if two hardware watchpoint
registers were used to track these separately, one of them may not be
hit. Or if you have one Watchpoint on a variable with a condition set,
and another Watchpoint on that same variable with a command defined or
different condition, or ignorecount, both of those Watchpoints need to
evaluate their criteria/commands when their WatchpointResource has been
hit.
There's a bit of code movement to rearrange things in the direction I'll
need for implementing this feature, so I want to start with reviewing &
landing this mostly NFC patch and we can focus on the algorithmic
choices about how WatchpointResources are shared and handled as they're
triggeed, separately.
This patch also stops printing "Watchpoint <n> hit: old value: <x>, new
vlaue: <y>" for Read watchpoints. I could make an argument for print
"Watchpoint <n> hit: current value <x>" but the current output doesn't
make any sense, and the user can print the value if they are
particularly interested. Read watchpoints are used primarily to
understand what code is reading a variable.
This patch adds more fallbacks for how to print the objects being
watched if we have types, instead of assuming they are all integral
values, so a struct will print its elements. As large watchpoints are
added, we'll be doing a lot more of those.
To track the WatchpointSP in the WatchpointResources, I changed the
internal API which took a WatchpointSP and devolved it to a Watchpoint*,
which meant touching several different Process files. I removed the
watchpoint code in ProcessKDP which only reported that watchpoints
aren't supported, the base class does that already.
I haven't yet changed how we receive a watchpoint to identify the
WatchpointResource responsible for the trigger, and identify all
Watchpoints that are using this Resource to evaluate their conditions
etc. This is the same work that a BreakpointSite needs to do when it has
been tiggered, where multiple Breakpoints may be at the same address.
There is not yet any printing of the Resources that a Watchpoint is
implemented in terms of ("watchpoint list", or
SBWatchpoint::GetDescription).
"watchpoint set var" and "watchpoint set expression" take a size
argument which was previously 1, 2, 4, or 8 (an enum). I've changed this
to an unsigned int. Most hardware implementations can only watch 1, 2,
4, 8 byte ranges, but with Resources we'll allow a user to ask for
different sized watchpoints and set them in hardware-expressble terms
soon.
I've annotated areas where I know there is work still needed with
LWP_TODO that I'll be working on once this is landed.
I've tested this on aarch64 macOS, aarch64 Linux, and Intel macOS.
https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116
(cherry picked from commit fc6b72523f3d73b921690a713e97a433c96066c6)
2023-11-27 13:28:59 -08:00
|
|
|
|
|
|
|
|
if (values_ss.GetSize()) {
|
|
|
|
|
s->Printf("%s", values_ss.GetData());
|
|
|
|
|
printed_anything = true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return printed_anything;
|
2012-08-13 21:09:54 +00:00
|
|
|
}
|
|
|
|
|
|
2011-10-14 00:42:25 +00:00
|
|
|
void Watchpoint::DumpWithLevel(Stream *s,
|
|
|
|
|
lldb::DescriptionLevel description_level) const {
|
2011-10-17 18:58:00 +00:00
|
|
|
if (s == nullptr)
|
|
|
|
|
return;
|
2011-09-16 21:41:42 +00:00
|
|
|
|
|
|
|
|
assert(description_level >= lldb::eDescriptionLevelBrief &&
|
|
|
|
|
description_level <= lldb::eDescriptionLevelVerbose);
|
2010-06-08 16:52:24 +00:00
|
|
|
|
2011-10-14 00:42:25 +00:00
|
|
|
s->Printf("Watchpoint %u: addr = 0x%8.8" PRIx64
|
2023-09-21 10:21:53 +00:00
|
|
|
" size = %u state = %s type = %s%s%s",
|
2012-01-24 00:11:02 +00:00
|
|
|
GetID(), GetLoadAddress(), m_byte_size,
|
2011-10-14 00:42:25 +00:00
|
|
|
IsEnabled() ? "enabled" : "disabled", m_watch_read ? "r" : "",
|
2023-09-21 10:21:53 +00:00
|
|
|
m_watch_write ? "w" : "", m_watch_modify ? "m" : "");
|
2010-06-08 16:52:24 +00:00
|
|
|
|
2012-08-21 23:17:04 +00:00
|
|
|
if (description_level >= lldb::eDescriptionLevelFull) {
|
|
|
|
|
if (!m_decl_str.empty())
|
|
|
|
|
s->Printf("\n declare @ '%s'", m_decl_str.c_str());
|
|
|
|
|
if (!m_watch_spec_str.empty())
|
|
|
|
|
s->Printf("\n watchpoint spec = '%s'", m_watch_spec_str.c_str());
|
[lldb] Add support for large watchpoints in lldb (#79962)
This patch is the next piece of work in my Large Watchpoint proposal,
https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116
This patch breaks a user's watchpoint into one or more
WatchpointResources which reflect what the hardware registers can cover.
This means we can watch objects larger than 8 bytes, and we can watched
unaligned address ranges. On a typical 64-bit target with 4 watchpoint
registers you can watch 32 bytes of memory if the start address is
doubleword aligned.
Additionally, if the remote stub implements AArch64 MASK style
watchpoints (e.g. debugserver on Darwin), we can watch any power-of-2
size region of memory up to 2GB, aligned to that same size.
I updated the Watchpoint constructor and CommandObjectWatchpoint to
create a CompilerType of Array<UInt8> when the size of the watched
region is greater than pointer-size and we don't have a variable type to
use. For pointer-size and smaller, we can display the watched granule as
an integer value; for larger-than-pointer-size we will display as an
array of bytes.
I have `watchpoint list` now print the WatchpointResources used to
implement the watchpoint.
I added a WatchpointAlgorithm class which has a top-level static method
that takes an enum flag mask WatchpointHardwareFeature and a user
address and size, and returns a vector of WatchpointResources covering
the request. It does not take into account the number of watchpoint
registers the target has, or the number still available for use. Right
now there is only one algorithm, which monitors power-of-2 regions of
memory. For up to pointer-size, this is what Intel hardware supports.
AArch64 Byte Address Select watchpoints can watch any number of
contiguous bytes in a pointer-size memory granule, that is not currently
supported so if you ask to watch bytes 3-5, the algorithm will watch the
entire doubleword (8 bytes). The newly default "modify" style means we
will silently ignore modifications to bytes outside the watched range.
I've temporarily skipped TestLargeWatchpoint.py for all targets. It was
only run on Darwin when using the in-tree debugserver, which was a proxy
for "debugserver supports MASK watchpoints". I'll be adding the
aforementioned feature flag from the stub and enabling full mask
watchpoints when a debugserver with that feature is enabled, and
re-enable this test.
I added a new TestUnalignedLargeWatchpoint.py which only has one test
but it's a great one, watching a 22-byte range that is unaligned and
requires four 8-byte watchpoints to cover.
I also added a unit test, WatchpointAlgorithmsTests, which has a number
of simple tests against WatchpointAlgorithms::PowerOf2Watchpoints. I
think there's interesting possible different approaches to how we cover
these; I note in the unit test that a user requesting a watch on address
0x12e0 of 120 bytes will be covered by two watchpoints today, a
128-bytes at 0x1280 and at 0x1300. But it could be done with a 16-byte
watchpoint at 0x12e0 and a 128-byte at 0x1300, which would have fewer
false positives/private stops. As we try refining this one, it's helpful
to have a collection of tests to make sure things don't regress.
I tested this on arm64 macOS, (genuine) x86_64 macOS, and AArch64
Ubuntu. I have not modifed the Windows process plugins yet, I might try
that as a standalone patch, I'd be making the change blind, but the
necessary changes (see ProcessGDBRemote::EnableWatchpoint) are pretty
small so it might be obvious enough that I can change it and see what
the Windows CI thinks.
There isn't yet a packet (or a qSupported feature query) for the gdb
remote serial protocol stub to communicate its watchpoint capabilities
to lldb. I'll be doing that in a patch right after this is landed,
having debugserver advertise its capability of AArch64 MASK watchpoints,
and have ProcessGDBRemote add eWatchpointHardwareArmMASK to
WatchpointAlgorithms so we can watch larger than 32-byte requests on
Darwin.
I haven't yet tackled WatchpointResource *sharing* by multiple
Watchpoints. This is all part of the goal, especially when we may be
watching a larger memory range than the user requested, if they then add
another watchpoint next to their first request, it may be covered by the
same WatchpointResource (hardware watchpoint register). Also one "read"
watchpoint and one "write" watchpoint on the same memory granule need to
be handled, making the WatchpointResource cover all requests.
As WatchpointResources aren't shared among multiple Watchpoints yet,
there's no handling of running the conditions/commands/etc on multiple
Watchpoints when their shared WatchpointResource is hit. The goal beyond
"large watchpoint" is to unify (much more) the Watchpoint and Breakpoint
behavior and commands. I have a feeling I may be slowly chipping away at
this for a while.
Re-landing this patch after fixing two undefined behaviors in
WatchpointAlgorithms found by UBSan and by failures on different
CI bots.
rdar://108234227
2024-01-31 21:01:59 -08:00
|
|
|
if (IsEnabled()) {
|
|
|
|
|
if (ProcessSP process_sp = m_target.GetProcessSP()) {
|
|
|
|
|
auto &resourcelist = process_sp->GetWatchpointResourceList();
|
|
|
|
|
size_t idx = 0;
|
|
|
|
|
s->Printf("\n watchpoint resources:");
|
|
|
|
|
for (WatchpointResourceSP &wpres : resourcelist.Sites()) {
|
|
|
|
|
if (wpres->ConstituentsContains(this)) {
|
|
|
|
|
s->Printf("\n #%zu: ", idx);
|
|
|
|
|
wpres->Dump(s);
|
|
|
|
|
}
|
|
|
|
|
idx++;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2012-08-21 23:17:04 +00:00
|
|
|
|
|
|
|
|
// Dump the snapshots we have taken.
|
|
|
|
|
DumpSnapshots(s, " ");
|
|
|
|
|
|
|
|
|
|
if (GetConditionText())
|
2012-08-23 22:28:26 +00:00
|
|
|
s->Printf("\n condition = '%s'", GetConditionText());
|
|
|
|
|
m_options.GetCallbackDescription(s, description_level);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (description_level >= lldb::eDescriptionLevelVerbose) {
|
Remove hardware index from watchpoints and breakpoints (#72012)
The Watchpoint and Breakpoint objects try to track the hardware index
that was used for them, if they are hardware wp/bp's. The majority of
our debugging goes over the gdb remote serial protocol, and when we set
the watchpoint/breakpoint, there is no (standard) way for the remote
stub to communicate to lldb which hardware index was used. We have an
lldb-extension packet to query the total number of watchpoint registers.
When a watchpoint is hit, there is an lldb extension to the stop reply
packet (documented in lldb-gdb-remote.txt) to describe the watchpoint
including its actual hardware index,
<addr within wp range> <wp hw index> <actual accessed address>
(the third field is specifically needed for MIPS). At this point, if the
stub reported these three fields (the stub is only required to provide
the first), we can know the actual hardware index for this watchpoint.
Breakpoints are worse; there's never any way for us to be notified about
which hardware index was used. Breakpoints got this as a side effect of
inherting from StoppointSite with Watchpoints.
We expose the watchpoint hardware index through "watchpoint list -v" and
through SBWatchpoint::GetHardwareIndex.
With my large watchpoint support, there is no *single* hardware index
that may be used for a watchpoint, it may need multiple resources. Also
I don't see what a user is supposed to do with this information, or an
IDE. Knowing the total number of watchpoint registers on the target, and
knowing how many Watchpoint Resources are currently in use, is helpful.
Knowing how many Watchpoint Resources
a single user-specified watchpoint needed to be implemented is useful.
But knowing which registers were used is an implementation detail and
not available until we hit the watchpoint when using gdb remote serial
protocol.
So given all that, I'm removing watchpoint hardware index numbers. I'm
changing the SB API to always return -1.
2023-11-15 13:32:42 -08:00
|
|
|
s->Printf("\n hit_count = %-4u ignore_count = %-4u", GetHitCount(),
|
|
|
|
|
GetIgnoreCount());
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2012-08-21 23:17:04 +00:00
|
|
|
}
|
|
|
|
|
|
2012-12-18 02:03:49 +00:00
|
|
|
bool Watchpoint::IsEnabled() const { return m_enabled; }
|
2010-06-08 16:52:24 +00:00
|
|
|
|
2012-12-18 02:03:49 +00:00
|
|
|
// Within StopInfo.cpp, we purposely turn on the ephemeral mode right before
|
2018-04-30 16:49:04 +00:00
|
|
|
// temporarily disable the watchpoint in order to perform possible watchpoint
|
|
|
|
|
// actions without triggering further watchpoint events. After the temporary
|
|
|
|
|
// disabled watchpoint is enabled, we then turn off the ephemeral mode.
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-12-18 02:03:49 +00:00
|
|
|
void Watchpoint::TurnOnEphemeralMode() { m_is_ephemeral = true; }
|
2010-06-08 16:52:24 +00:00
|
|
|
|
2011-10-14 00:42:25 +00:00
|
|
|
void Watchpoint::TurnOffEphemeralMode() {
|
2012-08-21 23:17:04 +00:00
|
|
|
m_is_ephemeral = false;
|
2011-10-14 00:42:25 +00:00
|
|
|
// Leaving ephemeral mode, reset the m_disabled_count!
|
2010-06-08 16:52:24 +00:00
|
|
|
m_disabled_count = 0;
|
|
|
|
|
}
|
2015-10-30 18:50:12 +00:00
|
|
|
|
2011-10-14 00:42:25 +00:00
|
|
|
bool Watchpoint::IsDisabledDuringEphemeralMode() {
|
2016-10-25 20:34:32 +00:00
|
|
|
return m_disabled_count > 1 && m_is_ephemeral;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
2015-10-30 18:50:12 +00:00
|
|
|
|
2011-10-14 00:42:25 +00:00
|
|
|
void Watchpoint::SetEnabled(bool enabled, bool notify) {
|
2010-06-08 16:52:24 +00:00
|
|
|
if (!enabled) {
|
Remove hardware index from watchpoints and breakpoints (#72012)
The Watchpoint and Breakpoint objects try to track the hardware index
that was used for them, if they are hardware wp/bp's. The majority of
our debugging goes over the gdb remote serial protocol, and when we set
the watchpoint/breakpoint, there is no (standard) way for the remote
stub to communicate to lldb which hardware index was used. We have an
lldb-extension packet to query the total number of watchpoint registers.
When a watchpoint is hit, there is an lldb extension to the stop reply
packet (documented in lldb-gdb-remote.txt) to describe the watchpoint
including its actual hardware index,
<addr within wp range> <wp hw index> <actual accessed address>
(the third field is specifically needed for MIPS). At this point, if the
stub reported these three fields (the stub is only required to provide
the first), we can know the actual hardware index for this watchpoint.
Breakpoints are worse; there's never any way for us to be notified about
which hardware index was used. Breakpoints got this as a side effect of
inherting from StoppointSite with Watchpoints.
We expose the watchpoint hardware index through "watchpoint list -v" and
through SBWatchpoint::GetHardwareIndex.
With my large watchpoint support, there is no *single* hardware index
that may be used for a watchpoint, it may need multiple resources. Also
I don't see what a user is supposed to do with this information, or an
IDE. Knowing the total number of watchpoint registers on the target, and
knowing how many Watchpoint Resources are currently in use, is helpful.
Knowing how many Watchpoint Resources
a single user-specified watchpoint needed to be implemented is useful.
But knowing which registers were used is an implementation detail and
not available until we hit the watchpoint when using gdb remote serial
protocol.
So given all that, I'm removing watchpoint hardware index numbers. I'm
changing the SB API to always return -1.
2023-11-15 13:32:42 -08:00
|
|
|
if (m_is_ephemeral)
|
2010-06-08 16:52:24 +00:00
|
|
|
++m_disabled_count;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
// Don't clear the snapshots for now.
|
|
|
|
|
// Within StopInfo.cpp, we purposely do disable/enable watchpoint while
|
2012-08-21 22:06:34 +00:00
|
|
|
// performing watchpoint actions.
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2012-12-18 02:03:49 +00:00
|
|
|
bool changed = enabled != m_enabled;
|
2010-06-08 16:52:24 +00:00
|
|
|
m_enabled = enabled;
|
2012-12-18 02:03:49 +00:00
|
|
|
if (notify && !m_is_ephemeral && changed)
|
|
|
|
|
SendWatchpointChangedEvent(enabled ? eWatchpointEventTypeEnabled
|
|
|
|
|
: eWatchpointEventTypeDisabled);
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
2011-10-14 00:42:25 +00:00
|
|
|
void Watchpoint::SetWatchpointType(uint32_t type, bool notify) {
|
|
|
|
|
int old_watch_read = m_watch_read;
|
2012-12-18 02:03:49 +00:00
|
|
|
int old_watch_write = m_watch_write;
|
2023-09-21 10:21:53 +00:00
|
|
|
int old_watch_modify = m_watch_modify;
|
2012-12-18 02:03:49 +00:00
|
|
|
m_watch_read = (type & LLDB_WATCH_TYPE_READ) != 0;
|
2010-06-08 16:52:24 +00:00
|
|
|
m_watch_write = (type & LLDB_WATCH_TYPE_WRITE) != 0;
|
2023-09-21 10:21:53 +00:00
|
|
|
m_watch_modify = (type & LLDB_WATCH_TYPE_MODIFY) != 0;
|
2012-12-18 02:03:49 +00:00
|
|
|
if (notify &&
|
2023-09-21 10:21:53 +00:00
|
|
|
(old_watch_read != m_watch_read || old_watch_write != m_watch_write ||
|
|
|
|
|
old_watch_modify != m_watch_modify))
|
2012-12-18 02:03:49 +00:00
|
|
|
SendWatchpointChangedEvent(eWatchpointEventTypeTypeChanged);
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
2011-10-17 18:58:00 +00:00
|
|
|
|
|
|
|
|
bool Watchpoint::WatchpointRead() const { return m_watch_read != 0; }
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-10-17 18:58:00 +00:00
|
|
|
bool Watchpoint::WatchpointWrite() const { return m_watch_write != 0; }
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2023-09-21 10:21:53 +00:00
|
|
|
bool Watchpoint::WatchpointModify() const { return m_watch_modify != 0; }
|
|
|
|
|
|
2011-10-17 18:58:00 +00:00
|
|
|
uint32_t Watchpoint::GetIgnoreCount() const { return m_ignore_count; }
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-10-17 18:58:00 +00:00
|
|
|
void Watchpoint::SetIgnoreCount(uint32_t n) {
|
2012-12-18 02:03:49 +00:00
|
|
|
bool changed = m_ignore_count != n;
|
2012-08-09 23:09:42 +00:00
|
|
|
m_ignore_count = n;
|
|
|
|
|
if (changed)
|
|
|
|
|
SendWatchpointChangedEvent(eWatchpointEventTypeIgnoreChanged);
|
2011-10-17 18:58:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool Watchpoint::InvokeCallback(StoppointCallbackContext *context) {
|
2015-10-30 18:50:12 +00:00
|
|
|
return m_options.InvokeCallback(context, GetID());
|
2011-10-17 18:58:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Watchpoint::SetCondition(const char *condition) {
|
|
|
|
|
if (condition == nullptr || condition[0] == '\0') {
|
2019-02-13 06:25:41 +00:00
|
|
|
if (m_condition_up)
|
|
|
|
|
m_condition_up.reset();
|
2016-09-06 20:57:50 +00:00
|
|
|
} else {
|
2015-10-30 18:50:12 +00:00
|
|
|
// Pass nullptr for expr_prefix (no translation-unit level definitions).
|
2017-05-12 04:51:55 +00:00
|
|
|
Status error;
|
2024-08-28 15:49:40 +10:00
|
|
|
m_condition_up.reset(m_target.GetUserExpressionForLanguage(
|
2024-04-29 13:26:24 -07:00
|
|
|
condition, {}, {}, UserExpression::eResultTypeAny,
|
2024-08-28 15:49:40 +10:00
|
|
|
EvaluateExpressionOptions(), nullptr, error));
|
2015-09-15 21:13:50 +00:00
|
|
|
if (error.Fail()) {
|
|
|
|
|
// FIXME: Log something...
|
2019-02-13 06:25:41 +00:00
|
|
|
m_condition_up.reset();
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
}
|
2012-12-18 02:03:49 +00:00
|
|
|
SendWatchpointChangedEvent(eWatchpointEventTypeConditionChanged);
|
2011-10-17 18:58:00 +00:00
|
|
|
}
|
|
|
|
|
|
2012-12-18 02:03:49 +00:00
|
|
|
const char *Watchpoint::GetConditionText() const {
|
2019-02-13 06:25:41 +00:00
|
|
|
if (m_condition_up)
|
|
|
|
|
return m_condition_up->GetUserText();
|
2016-09-06 20:57:50 +00:00
|
|
|
else
|
2012-12-18 02:03:49 +00:00
|
|
|
return nullptr;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Watchpoint::SendWatchpointChangedEvent(
|
|
|
|
|
lldb::WatchpointEventType eventKind) {
|
2024-01-31 14:44:52 -08:00
|
|
|
if (GetTarget().EventTypeHasListeners(
|
|
|
|
|
Target::eBroadcastBitWatchpointChanged)) {
|
2024-01-22 10:46:20 -08:00
|
|
|
auto data_sp =
|
|
|
|
|
std::make_shared<WatchpointEventData>(eventKind, shared_from_this());
|
|
|
|
|
GetTarget().BroadcastEvent(Target::eBroadcastBitWatchpointChanged, data_sp);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2012-12-18 02:03:49 +00:00
|
|
|
}
|
|
|
|
|
|
2015-10-30 18:50:12 +00:00
|
|
|
Watchpoint::WatchpointEventData::WatchpointEventData(
|
2012-12-18 02:03:49 +00:00
|
|
|
WatchpointEventType sub_type, const WatchpointSP &new_watchpoint_sp)
|
2022-02-06 10:54:46 -08:00
|
|
|
: m_watchpoint_event(sub_type), m_new_watchpoint_sp(new_watchpoint_sp) {}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-10-30 18:50:12 +00:00
|
|
|
Watchpoint::WatchpointEventData::~WatchpointEventData() = default;
|
2012-12-18 02:03:49 +00:00
|
|
|
|
2023-04-07 18:39:24 -07:00
|
|
|
llvm::StringRef Watchpoint::WatchpointEventData::GetFlavorString() {
|
|
|
|
|
return "Watchpoint::WatchpointEventData";
|
2012-12-18 02:03:49 +00:00
|
|
|
}
|
|
|
|
|
|
2023-04-07 18:39:24 -07:00
|
|
|
llvm::StringRef Watchpoint::WatchpointEventData::GetFlavor() const {
|
2012-12-18 02:03:49 +00:00
|
|
|
return WatchpointEventData::GetFlavorString();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
WatchpointSP &Watchpoint::WatchpointEventData::GetWatchpoint() {
|
|
|
|
|
return m_new_watchpoint_sp;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
WatchpointEventType
|
|
|
|
|
Watchpoint::WatchpointEventData::GetWatchpointEventType() const {
|
|
|
|
|
return m_watchpoint_event;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void Watchpoint::WatchpointEventData::Dump(Stream *s) const {}
|
|
|
|
|
|
|
|
|
|
const Watchpoint::WatchpointEventData *
|
|
|
|
|
Watchpoint::WatchpointEventData::GetEventDataFromEvent(const Event *event) {
|
|
|
|
|
if (event) {
|
|
|
|
|
const EventData *event_data = event->GetData();
|
|
|
|
|
if (event_data &&
|
|
|
|
|
event_data->GetFlavor() == WatchpointEventData::GetFlavorString())
|
|
|
|
|
return static_cast<const WatchpointEventData *>(event->GetData());
|
|
|
|
|
}
|
2015-10-30 18:50:12 +00:00
|
|
|
return nullptr;
|
2012-12-18 02:03:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
WatchpointEventType
|
|
|
|
|
Watchpoint::WatchpointEventData::GetWatchpointEventTypeFromEvent(
|
|
|
|
|
const EventSP &event_sp) {
|
|
|
|
|
const WatchpointEventData *data = GetEventDataFromEvent(event_sp.get());
|
|
|
|
|
|
2015-10-30 18:50:12 +00:00
|
|
|
if (data == nullptr)
|
2012-12-18 02:03:49 +00:00
|
|
|
return eWatchpointEventTypeInvalidType;
|
|
|
|
|
else
|
|
|
|
|
return data->GetWatchpointEventType();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
WatchpointSP Watchpoint::WatchpointEventData::GetWatchpointFromEvent(
|
|
|
|
|
const EventSP &event_sp) {
|
|
|
|
|
WatchpointSP wp_sp;
|
|
|
|
|
|
|
|
|
|
const WatchpointEventData *data = GetEventDataFromEvent(event_sp.get());
|
|
|
|
|
if (data)
|
|
|
|
|
wp_sp = data->m_new_watchpoint_sp;
|
|
|
|
|
|
|
|
|
|
return wp_sp;
|
|
|
|
|
}
|
