[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
|
|
|
//===-- StopInfo.cpp ------------------------------------------------------===//
|
2010-08-04 01:40:35 +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-08-04 01:40:35 +00:00
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
|
|
#include <string>
|
|
|
|
|
|
2010-11-18 18:52:36 +00:00
|
|
|
#include "lldb/Breakpoint/Breakpoint.h"
|
2010-08-04 01:40:35 +00:00
|
|
|
#include "lldb/Breakpoint/BreakpointLocation.h"
|
|
|
|
|
#include "lldb/Breakpoint/StoppointCallbackContext.h"
|
2011-10-14 00:42:25 +00:00
|
|
|
#include "lldb/Breakpoint/Watchpoint.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"
|
2011-08-09 02:12:22 +00:00
|
|
|
#include "lldb/Core/Debugger.h"
|
2015-09-15 21:13:50 +00:00
|
|
|
#include "lldb/Expression/UserExpression.h"
|
2024-10-30 09:28:38 -07:00
|
|
|
#include "lldb/Symbol/Block.h"
|
2010-08-04 01:40:35 +00:00
|
|
|
#include "lldb/Target/Process.h"
|
2015-10-23 18:39:37 +00:00
|
|
|
#include "lldb/Target/StopInfo.h"
|
2011-08-09 02:12:22 +00:00
|
|
|
#include "lldb/Target/Target.h"
|
2010-08-04 01:40:35 +00:00
|
|
|
#include "lldb/Target/Thread.h"
|
|
|
|
|
#include "lldb/Target/ThreadPlan.h"
|
2022-07-27 09:27:51 -07:00
|
|
|
#include "lldb/Target/ThreadPlanStepInstruction.h"
|
2010-08-04 01:40:35 +00:00
|
|
|
#include "lldb/Target/UnixSignals.h"
|
2022-02-03 13:26:10 +01:00
|
|
|
#include "lldb/Utility/LLDBLog.h"
|
2017-03-03 20:56:28 +00:00
|
|
|
#include "lldb/Utility/Log.h"
|
2017-02-02 21:39:50 +00:00
|
|
|
#include "lldb/Utility/StreamString.h"
|
2024-10-24 20:20:48 -07:00
|
|
|
#include "lldb/ValueObject/ValueObject.h"
|
2010-08-04 01:40:35 +00:00
|
|
|
|
|
|
|
|
using namespace lldb;
|
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
|
|
|
|
|
StopInfo::StopInfo(Thread &thread, uint64_t value)
|
2013-04-29 23:30:46 +00:00
|
|
|
: m_thread_wp(thread.shared_from_this()),
|
2012-02-21 00:09:25 +00:00
|
|
|
m_stop_id(thread.GetProcess()->GetStopID()),
|
|
|
|
|
m_resume_id(thread.GetProcess()->GetResumeID()), m_value(value),
|
Figure out the reply to "PlanExplainsStop" once when we stop and then use the cached
value. This fixes problems, for instance, with the StepRange plans, where they know that
they explained the stop because they were at their "run to here" breakpoint, then deleted
that breakpoint, so when they got asked again, doh! I had done this for a couple of plans
in an ad hoc fashion, this just formalizes it.
Also add a "ResumeRequested" in Process so that the code in the completion handlers can
tell the ShouldStop logic they want to resume rather than just directly resuming. That allows
us to handle resuming in a more controlled fashion.
Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when
the target was immediately restarted.
--This line, and those below , will be ignored--
M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py
M include/lldb/Target/ThreadList.h
M include/lldb/Target/ThreadPlanStepOut.h
M include/lldb/Target/Thread.h
M include/lldb/Target/ThreadPlanBase.h
M include/lldb/Target/ThreadPlanStepThrough.h
M include/lldb/Target/ThreadPlanStepInstruction.h
M include/lldb/Target/ThreadPlanStepInRange.h
M include/lldb/Target/ThreadPlanStepOverBreakpoint.h
M include/lldb/Target/ThreadPlanStepUntil.h
M include/lldb/Target/StopInfo.h
M include/lldb/Target/Process.h
M include/lldb/Target/ThreadPlanRunToAddress.h
M include/lldb/Target/ThreadPlan.h
M include/lldb/Target/ThreadPlanCallFunction.h
M include/lldb/Target/ThreadPlanStepOverRange.h
M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h
M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp
M source/Target/StopInfo.cpp
M source/Target/Process.cpp
M source/Target/ThreadPlanRunToAddress.cpp
M source/Target/ThreadPlan.cpp
M source/Target/ThreadPlanCallFunction.cpp
M source/Target/ThreadPlanStepOverRange.cpp
M source/Target/ThreadList.cpp
M source/Target/ThreadPlanStepOut.cpp
M source/Target/Thread.cpp
M source/Target/ThreadPlanBase.cpp
M source/Target/ThreadPlanStepThrough.cpp
M source/Target/ThreadPlanStepInstruction.cpp
M source/Target/ThreadPlanStepInRange.cpp
M source/Target/ThreadPlanStepOverBreakpoint.cpp
M source/Target/ThreadPlanStepUntil.cpp
M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme
llvm-svn: 181381
2013-05-08 00:35:16 +00:00
|
|
|
m_description(), m_override_should_notify(eLazyBoolCalculate),
|
LLDB AddressSanitizer instrumentation runtime plugin, breakpint on error and report data extraction
Reviewed at http://reviews.llvm.org/D5592
This patch gives LLDB some ability to interact with AddressSanitizer runtime library, on top of what we already have (historical memory stack traces provided by ASan). Namely, that's the ability to stop on an error caught by ASan, and access the report information that are associated with it. The report information is also exposed into SB API.
More precisely this patch...
adds a new plugin type, InstrumentationRuntime, which should serve as a generic superclass for other instrumentation runtime libraries, these plugins get notified when modules are loaded, so they get a chance to "activate" when a specific dynamic library is loaded
an instance of this plugin type, AddressSanitizerRuntime, which activates itself when it sees the ASan dynamic library or founds ASan statically linked in the executable
adds a collection of these plugins into the Process class
AddressSanitizerRuntime sets an internal breakpoint on __asan::AsanDie(), and when this breakpoint gets hit, it retrieves the report information from ASan
this breakpoint is then exposed as a new StopReason, eStopReasonInstrumentation, with a new StopInfo subclass, InstrumentationRuntimeStopInfo
the StopInfo superclass is extended with a m_extended_info field (it's a StructuredData::ObjectSP), that can hold arbitrary JSON-like data, which is the way the new plugin provides the report data
the "thread info" command now accepts a "-s" flag that prints out the JSON data of a stop reason (same way the "-j" flag works now)
SBThread has a new API, GetStopReasonExtendedInfoAsJSON, which dumps the JSON string into a SBStream
adds a test case for all of this
I plan to also get rid of the original ASan plugin (memory history stack traces) and use an instance of AddressSanitizerRuntime for that purpose.
Kuba
llvm-svn: 219546
2014-10-10 23:43:03 +00:00
|
|
|
m_override_should_stop(eLazyBoolCalculate), m_extended_info() {}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
LLDB AddressSanitizer instrumentation runtime plugin, breakpint on error and report data extraction
Reviewed at http://reviews.llvm.org/D5592
This patch gives LLDB some ability to interact with AddressSanitizer runtime library, on top of what we already have (historical memory stack traces provided by ASan). Namely, that's the ability to stop on an error caught by ASan, and access the report information that are associated with it. The report information is also exposed into SB API.
More precisely this patch...
adds a new plugin type, InstrumentationRuntime, which should serve as a generic superclass for other instrumentation runtime libraries, these plugins get notified when modules are loaded, so they get a chance to "activate" when a specific dynamic library is loaded
an instance of this plugin type, AddressSanitizerRuntime, which activates itself when it sees the ASan dynamic library or founds ASan statically linked in the executable
adds a collection of these plugins into the Process class
AddressSanitizerRuntime sets an internal breakpoint on __asan::AsanDie(), and when this breakpoint gets hit, it retrieves the report information from ASan
this breakpoint is then exposed as a new StopReason, eStopReasonInstrumentation, with a new StopInfo subclass, InstrumentationRuntimeStopInfo
the StopInfo superclass is extended with a m_extended_info field (it's a StructuredData::ObjectSP), that can hold arbitrary JSON-like data, which is the way the new plugin provides the report data
the "thread info" command now accepts a "-s" flag that prints out the JSON data of a stop reason (same way the "-j" flag works now)
SBThread has a new API, GetStopReasonExtendedInfoAsJSON, which dumps the JSON string into a SBStream
adds a test case for all of this
I plan to also get rid of the original ASan plugin (memory history stack traces) and use an instance of AddressSanitizerRuntime for that purpose.
Kuba
llvm-svn: 219546
2014-10-10 23:43:03 +00:00
|
|
|
bool StopInfo::IsValid() const {
|
2013-04-29 23:30:46 +00:00
|
|
|
ThreadSP thread_sp(m_thread_wp.lock());
|
|
|
|
|
if (thread_sp)
|
LLDB AddressSanitizer instrumentation runtime plugin, breakpint on error and report data extraction
Reviewed at http://reviews.llvm.org/D5592
This patch gives LLDB some ability to interact with AddressSanitizer runtime library, on top of what we already have (historical memory stack traces provided by ASan). Namely, that's the ability to stop on an error caught by ASan, and access the report information that are associated with it. The report information is also exposed into SB API.
More precisely this patch...
adds a new plugin type, InstrumentationRuntime, which should serve as a generic superclass for other instrumentation runtime libraries, these plugins get notified when modules are loaded, so they get a chance to "activate" when a specific dynamic library is loaded
an instance of this plugin type, AddressSanitizerRuntime, which activates itself when it sees the ASan dynamic library or founds ASan statically linked in the executable
adds a collection of these plugins into the Process class
AddressSanitizerRuntime sets an internal breakpoint on __asan::AsanDie(), and when this breakpoint gets hit, it retrieves the report information from ASan
this breakpoint is then exposed as a new StopReason, eStopReasonInstrumentation, with a new StopInfo subclass, InstrumentationRuntimeStopInfo
the StopInfo superclass is extended with a m_extended_info field (it's a StructuredData::ObjectSP), that can hold arbitrary JSON-like data, which is the way the new plugin provides the report data
the "thread info" command now accepts a "-s" flag that prints out the JSON data of a stop reason (same way the "-j" flag works now)
SBThread has a new API, GetStopReasonExtendedInfoAsJSON, which dumps the JSON string into a SBStream
adds a test case for all of this
I plan to also get rid of the original ASan plugin (memory history stack traces) and use an instance of AddressSanitizerRuntime for that purpose.
Kuba
llvm-svn: 219546
2014-10-10 23:43:03 +00:00
|
|
|
return thread_sp->GetProcess()->GetStopID() == m_stop_id;
|
2013-04-29 23:30:46 +00:00
|
|
|
return false;
|
2010-08-04 01:40:35 +00:00
|
|
|
}
|
|
|
|
|
|
2011-01-20 02:03:18 +00:00
|
|
|
void StopInfo::MakeStopInfoValid() {
|
2013-04-29 23:30:46 +00:00
|
|
|
ThreadSP thread_sp(m_thread_wp.lock());
|
|
|
|
|
if (thread_sp) {
|
|
|
|
|
m_stop_id = thread_sp->GetProcess()->GetStopID();
|
|
|
|
|
m_resume_id = thread_sp->GetProcess()->GetResumeID();
|
|
|
|
|
}
|
2011-01-20 02:03:18 +00:00
|
|
|
}
|
|
|
|
|
|
2011-11-08 03:00:11 +00:00
|
|
|
bool StopInfo::HasTargetRunSinceMe() {
|
2013-04-29 23:30:46 +00:00
|
|
|
ThreadSP thread_sp(m_thread_wp.lock());
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-04-29 23:30:46 +00:00
|
|
|
if (thread_sp) {
|
|
|
|
|
lldb::StateType ret_type = thread_sp->GetProcess()->GetPrivateState();
|
|
|
|
|
if (ret_type == eStateRunning) {
|
|
|
|
|
return true;
|
|
|
|
|
} else if (ret_type == eStateStopped) {
|
|
|
|
|
// This is a little tricky. We want to count "run and stopped again
|
2018-04-30 16:49:04 +00:00
|
|
|
// before you could ask this question as a "TRUE" answer to
|
|
|
|
|
// HasTargetRunSinceMe. But we don't want to include any running of the
|
|
|
|
|
// target done for expressions. So we track both resumes, and resumes
|
|
|
|
|
// caused by expressions, and check if there are any resumes
|
2013-04-29 23:30:46 +00:00
|
|
|
// NOT caused
|
|
|
|
|
// by expressions.
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-04-29 23:30:46 +00:00
|
|
|
uint32_t curr_resume_id = thread_sp->GetProcess()->GetResumeID();
|
|
|
|
|
uint32_t last_user_expression_id =
|
|
|
|
|
thread_sp->GetProcess()->GetLastUserExpressionResumeID();
|
|
|
|
|
if (curr_resume_id == m_resume_id) {
|
|
|
|
|
return false;
|
|
|
|
|
} else if (curr_resume_id > last_user_expression_id) {
|
|
|
|
|
return true;
|
2011-11-08 03:00:11 +00:00
|
|
|
}
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2011-11-08 03:00:11 +00:00
|
|
|
return false;
|
2011-08-09 02:12:22 +00:00
|
|
|
}
|
|
|
|
|
|
2010-08-04 01:40:35 +00:00
|
|
|
// StopInfoBreakpoint
|
|
|
|
|
|
2011-08-09 02:12:22 +00:00
|
|
|
namespace lldb_private {
|
2010-08-04 01:40:35 +00:00
|
|
|
class StopInfoBreakpoint : public StopInfo {
|
|
|
|
|
public:
|
|
|
|
|
StopInfoBreakpoint(Thread &thread, break_id_t break_id)
|
|
|
|
|
: StopInfo(thread, break_id), m_should_stop(false),
|
2011-02-08 05:20:59 +00:00
|
|
|
m_should_stop_is_valid(false), m_should_perform_action(true),
|
2012-10-05 19:16:31 +00:00
|
|
|
m_address(LLDB_INVALID_ADDRESS), m_break_id(LLDB_INVALID_BREAK_ID),
|
2022-06-16 11:46:25 -07:00
|
|
|
m_was_all_internal(false), m_was_one_shot(false) {
|
2012-10-05 19:16:31 +00:00
|
|
|
StoreBPInfo();
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2010-10-14 23:45:03 +00:00
|
|
|
StopInfoBreakpoint(Thread &thread, break_id_t break_id, bool should_stop)
|
|
|
|
|
: StopInfo(thread, break_id), m_should_stop(should_stop),
|
2011-10-28 01:12:19 +00:00
|
|
|
m_should_stop_is_valid(true), m_should_perform_action(true),
|
2012-10-05 19:16:31 +00:00
|
|
|
m_address(LLDB_INVALID_ADDRESS), m_break_id(LLDB_INVALID_BREAK_ID),
|
2022-06-16 11:46:25 -07:00
|
|
|
m_was_all_internal(false), m_was_one_shot(false) {
|
2012-10-05 19:16:31 +00:00
|
|
|
StoreBPInfo();
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2015-10-23 18:39:37 +00:00
|
|
|
~StopInfoBreakpoint() override = default;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-10-05 19:16:31 +00:00
|
|
|
void StoreBPInfo() {
|
2013-04-29 23:30:46 +00:00
|
|
|
ThreadSP thread_sp(m_thread_wp.lock());
|
|
|
|
|
if (thread_sp) {
|
|
|
|
|
BreakpointSiteSP bp_site_sp(
|
|
|
|
|
thread_sp->GetProcess()->GetBreakpointSiteList().FindByID(m_value));
|
|
|
|
|
if (bp_site_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
|
|
|
uint32_t num_constituents = bp_site_sp->GetNumberOfConstituents();
|
|
|
|
|
if (num_constituents == 1) {
|
|
|
|
|
BreakpointLocationSP bp_loc_sp = bp_site_sp->GetConstituentAtIndex(0);
|
2013-04-29 23:30:46 +00:00
|
|
|
if (bp_loc_sp) {
|
2022-06-16 11:46:25 -07:00
|
|
|
Breakpoint & bkpt = bp_loc_sp->GetBreakpoint();
|
|
|
|
|
m_break_id = bkpt.GetID();
|
|
|
|
|
m_was_one_shot = bkpt.IsOneShot();
|
|
|
|
|
m_was_all_internal = bkpt.IsInternal();
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
m_was_all_internal = true;
|
[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
|
|
|
for (uint32_t i = 0; i < num_constituents; i++) {
|
|
|
|
|
if (!bp_site_sp->GetConstituentAtIndex(i)
|
|
|
|
|
->GetBreakpoint()
|
|
|
|
|
.IsInternal()) {
|
2022-06-16 11:46:25 -07:00
|
|
|
m_was_all_internal = false;
|
|
|
|
|
break;
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
}
|
2013-04-29 23:30:46 +00:00
|
|
|
m_address = bp_site_sp->GetLoadAddress();
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2010-08-04 01:40:35 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2010-10-14 23:45:03 +00:00
|
|
|
bool IsValidForOperatingSystemThread(Thread &thread) override {
|
|
|
|
|
ProcessSP process_sp(thread.GetProcess());
|
|
|
|
|
if (process_sp) {
|
|
|
|
|
BreakpointSiteSP bp_site_sp(
|
|
|
|
|
process_sp->GetBreakpointSiteList().FindByID(m_value));
|
|
|
|
|
if (bp_site_sp)
|
2021-06-11 17:00:46 -07:00
|
|
|
return bp_site_sp->ValidForThisThread(thread);
|
2012-10-05 19:16:31 +00:00
|
|
|
}
|
2015-10-23 18:39:37 +00:00
|
|
|
return false;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2015-10-23 18:39:37 +00:00
|
|
|
StopReason GetStopReason() const override { return eStopReasonBreakpoint; }
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-04-29 23:30:46 +00:00
|
|
|
bool ShouldStopSynchronous(Event *event_ptr) override {
|
|
|
|
|
ThreadSP thread_sp(m_thread_wp.lock());
|
|
|
|
|
if (thread_sp) {
|
2011-10-28 01:12:19 +00:00
|
|
|
if (!m_should_stop_is_valid) {
|
2013-04-29 23:30:46 +00:00
|
|
|
// Only check once if we should stop at a breakpoint
|
|
|
|
|
BreakpointSiteSP bp_site_sp(
|
|
|
|
|
thread_sp->GetProcess()->GetBreakpointSiteList().FindByID(m_value));
|
|
|
|
|
if (bp_site_sp) {
|
|
|
|
|
ExecutionContext exe_ctx(thread_sp->GetStackFrameAtIndex(0));
|
|
|
|
|
StoppointCallbackContext context(event_ptr, exe_ctx, true);
|
|
|
|
|
bp_site_sp->BumpHitCounts();
|
|
|
|
|
m_should_stop = bp_site_sp->ShouldStop(&context);
|
2016-09-06 20:57:50 +00:00
|
|
|
} else {
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Process);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"Process::%s could not find breakpoint site id: %" PRId64
|
|
|
|
|
"...",
|
|
|
|
|
__FUNCTION__, m_value);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-04-29 23:30:46 +00:00
|
|
|
m_should_stop = true;
|
2011-10-28 01:12:19 +00:00
|
|
|
}
|
2013-04-29 23:30:46 +00:00
|
|
|
m_should_stop_is_valid = true;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2013-04-29 23:30:46 +00:00
|
|
|
return m_should_stop;
|
2010-10-14 23:45:03 +00:00
|
|
|
}
|
2015-10-23 18:39:37 +00:00
|
|
|
return false;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2015-10-23 18:39:37 +00:00
|
|
|
bool DoShouldNotify(Event *event_ptr) override {
|
2022-06-16 11:46:25 -07:00
|
|
|
return !m_was_all_internal;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2015-10-23 18:39:37 +00:00
|
|
|
const char *GetDescription() override {
|
|
|
|
|
if (m_description.empty()) {
|
2013-04-29 23:30:46 +00:00
|
|
|
ThreadSP thread_sp(m_thread_wp.lock());
|
|
|
|
|
if (thread_sp) {
|
|
|
|
|
BreakpointSiteSP bp_site_sp(
|
|
|
|
|
thread_sp->GetProcess()->GetBreakpointSiteList().FindByID(m_value));
|
|
|
|
|
if (bp_site_sp) {
|
|
|
|
|
StreamString strm;
|
|
|
|
|
// If we have just hit an internal breakpoint, and it has a kind
|
2018-04-30 16:49:04 +00:00
|
|
|
// description, print that instead of the full breakpoint printing:
|
2013-04-29 23:30:46 +00:00
|
|
|
if (bp_site_sp->IsInternal()) {
|
[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
|
|
|
size_t num_constituents = bp_site_sp->GetNumberOfConstituents();
|
|
|
|
|
for (size_t idx = 0; idx < num_constituents; idx++) {
|
|
|
|
|
const char *kind = bp_site_sp->GetConstituentAtIndex(idx)
|
2013-04-29 23:30:46 +00:00
|
|
|
->GetBreakpoint()
|
|
|
|
|
.GetBreakpointKind();
|
|
|
|
|
if (kind != nullptr) {
|
|
|
|
|
m_description.assign(kind);
|
|
|
|
|
return kind;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2013-04-29 23:30:46 +00:00
|
|
|
strm.Printf("breakpoint ");
|
|
|
|
|
bp_site_sp->GetDescription(&strm, eDescriptionLevelBrief);
|
2020-01-28 20:23:46 +01:00
|
|
|
m_description = std::string(strm.GetString());
|
2016-09-06 20:57:50 +00:00
|
|
|
} else {
|
2013-04-29 23:30:46 +00:00
|
|
|
StreamString strm;
|
|
|
|
|
if (m_break_id != LLDB_INVALID_BREAK_ID) {
|
|
|
|
|
BreakpointSP break_sp =
|
|
|
|
|
thread_sp->GetProcess()->GetTarget().GetBreakpointByID(
|
|
|
|
|
m_break_id);
|
|
|
|
|
if (break_sp) {
|
|
|
|
|
if (break_sp->IsInternal()) {
|
|
|
|
|
const char *kind = break_sp->GetBreakpointKind();
|
|
|
|
|
if (kind)
|
|
|
|
|
strm.Printf("internal %s breakpoint(%d).", kind, m_break_id);
|
|
|
|
|
else
|
|
|
|
|
strm.Printf("internal breakpoint(%d).", m_break_id);
|
2016-09-06 20:57:50 +00:00
|
|
|
} else {
|
2013-04-29 23:30:46 +00:00
|
|
|
strm.Printf("breakpoint %d.", m_break_id);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2013-04-29 23:30:46 +00:00
|
|
|
} else {
|
|
|
|
|
if (m_was_one_shot)
|
|
|
|
|
strm.Printf("one-shot breakpoint %d", m_break_id);
|
2016-09-06 20:57:50 +00:00
|
|
|
else
|
2013-04-29 23:30:46 +00:00
|
|
|
strm.Printf("breakpoint %d which has been deleted.",
|
|
|
|
|
m_break_id);
|
2010-08-04 01:40:35 +00:00
|
|
|
}
|
2013-04-29 23:30:46 +00:00
|
|
|
} else if (m_address == LLDB_INVALID_ADDRESS)
|
|
|
|
|
strm.Printf("breakpoint site %" PRIi64
|
|
|
|
|
" which has been deleted - unknown address",
|
|
|
|
|
m_value);
|
2016-09-06 20:57:50 +00:00
|
|
|
else
|
2013-04-29 23:30:46 +00:00
|
|
|
strm.Printf("breakpoint site %" PRIi64
|
|
|
|
|
" which has been deleted - was at 0x%" PRIx64,
|
|
|
|
|
m_value, m_address);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2020-01-28 20:23:46 +01:00
|
|
|
m_description = std::string(strm.GetString());
|
2010-08-04 01:40:35 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2010-08-04 01:40:35 +00:00
|
|
|
}
|
2012-11-10 02:08:14 +00:00
|
|
|
return m_description.c_str();
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2024-10-30 09:28:38 -07:00
|
|
|
std::optional<uint32_t>
|
|
|
|
|
GetSuggestedStackFrameIndex(bool inlined_stack) override {
|
|
|
|
|
if (!inlined_stack)
|
|
|
|
|
return {};
|
|
|
|
|
|
|
|
|
|
ThreadSP thread_sp(m_thread_wp.lock());
|
|
|
|
|
if (!thread_sp)
|
|
|
|
|
return {};
|
|
|
|
|
BreakpointSiteSP bp_site_sp(
|
|
|
|
|
thread_sp->GetProcess()->GetBreakpointSiteList().FindByID(m_value));
|
|
|
|
|
if (!bp_site_sp)
|
|
|
|
|
return {};
|
|
|
|
|
|
|
|
|
|
return bp_site_sp->GetSuggestedStackFrameIndex();
|
|
|
|
|
}
|
|
|
|
|
|
2015-10-23 18:39:37 +00:00
|
|
|
protected:
|
|
|
|
|
bool ShouldStop(Event *event_ptr) override {
|
2018-04-30 16:49:04 +00:00
|
|
|
// This just reports the work done by PerformAction or the synchronous
|
|
|
|
|
// stop. It should only ever get called after they have had a chance to
|
|
|
|
|
// run.
|
2012-04-20 21:16:56 +00:00
|
|
|
assert(m_should_stop_is_valid);
|
|
|
|
|
return m_should_stop;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2012-11-10 02:08:14 +00:00
|
|
|
void PerformAction(Event *event_ptr) override {
|
2013-04-29 23:30:46 +00:00
|
|
|
if (!m_should_perform_action)
|
2016-09-06 20:57:50 +00:00
|
|
|
return;
|
2011-02-08 05:20:59 +00:00
|
|
|
m_should_perform_action = false;
|
2023-01-25 10:50:02 +03:00
|
|
|
bool all_stopping_locs_internal = true;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-04-29 23:30:46 +00:00
|
|
|
ThreadSP thread_sp(m_thread_wp.lock());
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-04-29 23:30:46 +00:00
|
|
|
if (thread_sp) {
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Breakpoints | LLDBLog::Step);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-04-29 23:30:46 +00:00
|
|
|
if (!thread_sp->IsValid()) {
|
|
|
|
|
// This shouldn't ever happen, but just in case, don't do more harm.
|
2012-11-10 02:08:14 +00:00
|
|
|
if (log) {
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log, "PerformAction got called with an invalid thread.");
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2013-04-29 23:30:46 +00:00
|
|
|
m_should_stop = true;
|
|
|
|
|
m_should_stop_is_valid = true;
|
2016-09-06 20:57:50 +00:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2013-04-29 23:30:46 +00:00
|
|
|
BreakpointSiteSP bp_site_sp(
|
|
|
|
|
thread_sp->GetProcess()->GetBreakpointSiteList().FindByID(m_value));
|
2015-04-23 00:28:25 +00:00
|
|
|
std::unordered_set<break_id_t> precondition_breakpoints;
|
2022-06-28 18:06:30 -07:00
|
|
|
// Breakpoints that fail their condition check are not considered to
|
|
|
|
|
// have been hit. If the only locations at this site have failed their
|
|
|
|
|
// conditions, we should change the stop-info to none. Otherwise, if we
|
|
|
|
|
// hit another breakpoint on a different thread which does stop, users
|
|
|
|
|
// will see a breakpont hit with a failed condition, which is wrong.
|
|
|
|
|
// Use this variable to tell us if that is true.
|
|
|
|
|
bool actually_hit_any_locations = false;
|
2013-04-29 23:30:46 +00:00
|
|
|
if (bp_site_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
|
|
|
// Let's copy the constituents list out of the site and store them in a
|
|
|
|
|
// local list. That way if one of the breakpoint actions changes the
|
|
|
|
|
// site, then we won't be operating on a bad list.
|
2015-07-29 17:51:36 +00:00
|
|
|
BreakpointLocationCollection site_locations;
|
[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
|
|
|
size_t num_constituents =
|
|
|
|
|
bp_site_sp->CopyConstituentsList(site_locations);
|
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 (num_constituents == 0) {
|
2011-12-09 04:17:31 +00:00
|
|
|
m_should_stop = true;
|
2022-06-28 18:06:30 -07:00
|
|
|
actually_hit_any_locations = true; // We're going to stop, don't
|
|
|
|
|
// change the stop info.
|
2016-09-06 20:57:50 +00:00
|
|
|
} else {
|
2018-04-30 16:49:04 +00:00
|
|
|
// We go through each location, and test first its precondition -
|
|
|
|
|
// this overrides everything. Note, we only do this once per
|
|
|
|
|
// breakpoint - not once per location... Then check the condition.
|
|
|
|
|
// If the condition says to stop, then we run the callback for that
|
|
|
|
|
// location. If that callback says to stop as well, then we set
|
|
|
|
|
// m_should_stop to true; we are going to stop. But we still want to
|
|
|
|
|
// give all the breakpoints whose conditions say we are going to stop
|
|
|
|
|
// a chance to run their callbacks. Of course if any callback
|
|
|
|
|
// restarts the target by putting "continue" in the callback, then
|
2013-04-29 23:30:46 +00:00
|
|
|
// we're going to restart, without running the rest of the callbacks.
|
2018-04-30 16:49:04 +00:00
|
|
|
// And in this case we will end up not stopping even if another
|
|
|
|
|
// location said we should stop. But that's better than not running
|
|
|
|
|
// all the callbacks.
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2021-03-22 18:41:12 -07:00
|
|
|
// There's one other complication here. We may have run an async
|
|
|
|
|
// breakpoint callback that said we should stop. We only want to
|
2021-10-27 18:33:17 -07:00
|
|
|
// override that if another breakpoint action says we shouldn't
|
2021-03-22 18:41:12 -07:00
|
|
|
// stop. If nobody else has an opinion, then we should stop if the
|
|
|
|
|
// async callback says we should. An example of this is the async
|
|
|
|
|
// shared library load notification breakpoint and the setting
|
|
|
|
|
// stop-on-sharedlibrary-events.
|
|
|
|
|
// We'll keep the async value in async_should_stop, and track whether
|
|
|
|
|
// anyone said we should NOT stop in actually_said_continue.
|
|
|
|
|
bool async_should_stop = false;
|
|
|
|
|
if (m_should_stop_is_valid)
|
|
|
|
|
async_should_stop = m_should_stop;
|
|
|
|
|
bool actually_said_continue = false;
|
|
|
|
|
|
2013-04-29 23:30:46 +00:00
|
|
|
m_should_stop = false;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2016-03-12 02:45:34 +00:00
|
|
|
// We don't select threads as we go through them testing breakpoint
|
2018-04-30 16:49:04 +00:00
|
|
|
// conditions and running commands. So we need to set the thread for
|
|
|
|
|
// expression evaluation here:
|
2016-03-12 02:45:34 +00:00
|
|
|
ThreadList::ExpressionExecutionThreadPusher thread_pusher(thread_sp);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-04-29 23:30:46 +00:00
|
|
|
ExecutionContext exe_ctx(thread_sp->GetStackFrameAtIndex(0));
|
|
|
|
|
Process *process = exe_ctx.GetProcessPtr();
|
2023-04-05 17:10:42 -07:00
|
|
|
if (process->GetModIDRef().IsRunningExpression()) {
|
2013-04-29 23:30:46 +00:00
|
|
|
// If we are in the middle of evaluating an expression, don't run
|
2018-04-30 16:49:04 +00:00
|
|
|
// asynchronous breakpoint commands or expressions. That could
|
|
|
|
|
// lead to infinite recursion if the command or condition re-calls
|
|
|
|
|
// the function with this breakpoint.
|
2013-04-29 23:30:46 +00:00
|
|
|
// TODO: We can keep a list of the breakpoints we've seen while
|
|
|
|
|
// running expressions in the nested
|
|
|
|
|
// PerformAction calls that can arise when the action runs a
|
2018-04-30 16:49:04 +00:00
|
|
|
// function that hits another breakpoint, and only stop running
|
|
|
|
|
// commands when we see the same breakpoint hit a second time.
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-04-29 23:30:46 +00:00
|
|
|
m_should_stop_is_valid = true;
|
2018-11-30 09:45:52 +00:00
|
|
|
|
|
|
|
|
// It is possible that the user has a breakpoint at the same site
|
|
|
|
|
// as the completed plan had (e.g. user has a breakpoint
|
|
|
|
|
// on a module entry point, and `ThreadPlanCallFunction` ends
|
|
|
|
|
// also there). We can't find an internal breakpoint in the loop
|
|
|
|
|
// later because it was already removed on the plan completion.
|
|
|
|
|
// So check if the plan was completed, and stop if so.
|
|
|
|
|
if (thread_sp->CompletedPlanOverridesBreakpoint()) {
|
|
|
|
|
m_should_stop = true;
|
|
|
|
|
thread_sp->ResetStopInfo();
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log, "StopInfoBreakpoint::PerformAction - Hit a "
|
|
|
|
|
"breakpoint while running an expression,"
|
|
|
|
|
" not running commands to avoid recursion.");
|
2013-04-29 23:30:46 +00:00
|
|
|
bool ignoring_breakpoints =
|
|
|
|
|
process->GetIgnoreBreakpointsInExpressions();
|
2022-10-03 17:19:12 -07:00
|
|
|
// Internal breakpoints should be allowed to do their job, we
|
|
|
|
|
// can make sure they don't do anything that would cause recursive
|
|
|
|
|
// command execution:
|
|
|
|
|
if (!m_was_all_internal) {
|
|
|
|
|
m_should_stop = !ignoring_breakpoints;
|
|
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"StopInfoBreakpoint::PerformAction - in expression, "
|
|
|
|
|
"continuing: %s.",
|
|
|
|
|
m_should_stop ? "true" : "false");
|
|
|
|
|
Debugger::ReportWarning(
|
|
|
|
|
"hit breakpoint while running function, skipping commands "
|
|
|
|
|
"and conditions to prevent recursion",
|
|
|
|
|
process->GetTarget().GetDebugger().GetID());
|
|
|
|
|
return;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-02-18 18:52:47 +00:00
|
|
|
StoppointCallbackContext context(event_ptr, exe_ctx, false);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2014-10-22 01:54:17 +00:00
|
|
|
// For safety's sake let's also grab an extra reference to the
|
[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
|
|
|
// breakpoint constituents of the locations we're going to examine,
|
|
|
|
|
// since the locations are going to have to get back to their
|
|
|
|
|
// breakpoints, and the locations don't keep their constituents alive.
|
|
|
|
|
// I'm just sticking the BreakpointSP's in a vector since I'm only
|
|
|
|
|
// using it to locally increment their retain counts.
|
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
|
|
|
std::vector<lldb::BreakpointSP> location_constituents;
|
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
|
|
|
for (size_t j = 0; j < num_constituents; j++) {
|
2015-07-29 17:51:36 +00:00
|
|
|
BreakpointLocationSP loc(site_locations.GetByIndex(j));
|
[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
|
|
|
location_constituents.push_back(
|
|
|
|
|
loc->GetBreakpoint().shared_from_this());
|
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
|
|
|
for (size_t j = 0; j < num_constituents; j++) {
|
2013-04-29 23:30:46 +00:00
|
|
|
lldb::BreakpointLocationSP bp_loc_sp = site_locations.GetByIndex(j);
|
2017-08-03 18:13:24 +00:00
|
|
|
StreamString loc_desc;
|
|
|
|
|
if (log) {
|
|
|
|
|
bp_loc_sp->GetDescription(&loc_desc, eDescriptionLevelBrief);
|
|
|
|
|
}
|
2013-04-29 23:30:46 +00:00
|
|
|
// If another action disabled this breakpoint or its location, then
|
|
|
|
|
// don't run the actions.
|
|
|
|
|
if (!bp_loc_sp->IsEnabled() ||
|
2016-02-18 18:52:47 +00:00
|
|
|
!bp_loc_sp->GetBreakpoint().IsEnabled())
|
2013-04-29 23:30:46 +00:00
|
|
|
continue;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-04-29 23:30:46 +00:00
|
|
|
// The breakpoint site may have many locations associated with it,
|
2018-04-30 16:49:04 +00:00
|
|
|
// not all of them valid for this thread. Skip the ones that
|
|
|
|
|
// aren't:
|
2021-06-11 17:00:46 -07:00
|
|
|
if (!bp_loc_sp->ValidForThisThread(*thread_sp)) {
|
2016-09-06 20:57:50 +00:00
|
|
|
if (log) {
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"Breakpoint %s hit on thread 0x%llx but it was not "
|
|
|
|
|
"for this thread, continuing.",
|
|
|
|
|
loc_desc.GetData(),
|
|
|
|
|
static_cast<unsigned long long>(thread_sp->GetID()));
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2013-04-29 23:30:46 +00:00
|
|
|
continue;
|
2012-11-10 02:08:14 +00:00
|
|
|
}
|
|
|
|
|
|
2013-04-29 23:30:46 +00:00
|
|
|
// First run the precondition, but since the precondition is per
|
2018-04-30 16:49:04 +00:00
|
|
|
// breakpoint, only run it once per breakpoint.
|
2013-04-29 23:30:46 +00:00
|
|
|
std::pair<std::unordered_set<break_id_t>::iterator, bool> result =
|
|
|
|
|
precondition_breakpoints.insert(
|
|
|
|
|
bp_loc_sp->GetBreakpoint().GetID());
|
|
|
|
|
if (!result.second)
|
|
|
|
|
continue;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-04-23 00:28:25 +00:00
|
|
|
bool precondition_result =
|
2013-04-29 23:30:46 +00:00
|
|
|
bp_loc_sp->GetBreakpoint().EvaluatePrecondition(context);
|
2021-03-22 18:41:12 -07:00
|
|
|
if (!precondition_result) {
|
|
|
|
|
actually_said_continue = true;
|
2013-04-29 23:30:46 +00:00
|
|
|
continue;
|
2021-03-22 18:41:12 -07:00
|
|
|
}
|
2013-04-29 23:30:46 +00:00
|
|
|
// Next run the condition for the breakpoint. If that says we
|
2018-04-30 16:49:04 +00:00
|
|
|
// should stop, then we'll run the callback for the breakpoint. If
|
|
|
|
|
// the callback says we shouldn't stop that will win.
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2022-06-28 18:06:30 -07:00
|
|
|
if (bp_loc_sp->GetConditionText() == nullptr)
|
|
|
|
|
actually_hit_any_locations = true;
|
|
|
|
|
else {
|
2017-05-12 04:51:55 +00:00
|
|
|
Status condition_error;
|
2013-04-29 23:30:46 +00:00
|
|
|
bool condition_says_stop =
|
|
|
|
|
bp_loc_sp->ConditionSaysStop(exe_ctx, condition_error);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-01-26 02:19:28 +00:00
|
|
|
if (!condition_error.Success()) {
|
2022-06-28 18:06:30 -07:00
|
|
|
// If the condition fails to evaluate, we are going to stop
|
|
|
|
|
// at it, so the location was hit.
|
|
|
|
|
actually_hit_any_locations = true;
|
2013-04-29 23:30:46 +00:00
|
|
|
const char *err_str =
|
2022-03-16 22:38:39 -07:00
|
|
|
condition_error.AsCString("<unknown error>");
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log, "Error evaluating condition: \"%s\"\n", err_str);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2022-03-16 22:38:39 -07:00
|
|
|
StreamString strm;
|
|
|
|
|
strm << "stopped due to an error evaluating condition of "
|
|
|
|
|
"breakpoint ";
|
|
|
|
|
bp_loc_sp->GetDescription(&strm, eDescriptionLevelBrief);
|
|
|
|
|
strm << ": \"" << bp_loc_sp->GetConditionText() << "\"\n";
|
|
|
|
|
strm << err_str;
|
2022-03-16 08:30:26 -07:00
|
|
|
|
|
|
|
|
Debugger::ReportError(
|
2022-03-16 22:38:39 -07:00
|
|
|
strm.GetString().str(),
|
2022-03-16 08:30:26 -07:00
|
|
|
exe_ctx.GetTargetRef().GetDebugger().GetID());
|
2016-09-06 20:57:50 +00:00
|
|
|
} else {
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"Condition evaluated for breakpoint %s on thread "
|
2020-04-07 01:06:02 +09:00
|
|
|
"0x%llx condition_says_stop: %i.",
|
2019-07-24 17:56:10 +00:00
|
|
|
loc_desc.GetData(),
|
|
|
|
|
static_cast<unsigned long long>(thread_sp->GetID()),
|
|
|
|
|
condition_says_stop);
|
2022-06-28 18:06:30 -07:00
|
|
|
if (condition_says_stop)
|
|
|
|
|
actually_hit_any_locations = true;
|
|
|
|
|
else {
|
2013-04-29 23:30:46 +00:00
|
|
|
// We don't want to increment the hit count of breakpoints if
|
2018-04-30 16:49:04 +00:00
|
|
|
// the condition fails. We've already bumped it by the time
|
|
|
|
|
// we get here, so undo the bump:
|
2013-04-29 23:30:46 +00:00
|
|
|
bp_loc_sp->UndoBumpHitCount();
|
2021-03-22 18:41:12 -07:00
|
|
|
actually_said_continue = true;
|
2013-04-29 23:30:46 +00:00
|
|
|
continue;
|
2012-11-10 02:08:14 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2012-11-10 02:08:14 +00:00
|
|
|
}
|
|
|
|
|
|
2021-06-01 16:14:08 -07:00
|
|
|
// We've done all the checks whose failure means "we consider lldb
|
|
|
|
|
// not to have hit the breakpoint". Now we're going to check for
|
|
|
|
|
// conditions that might continue after hitting. Start with the
|
|
|
|
|
// ignore count:
|
|
|
|
|
if (!bp_loc_sp->IgnoreCountShouldStop()) {
|
|
|
|
|
actually_said_continue = true;
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-03 18:13:24 +00:00
|
|
|
// Check the auto-continue bit on the location, do this before the
|
|
|
|
|
// callback since it may change this, but that would be for the
|
|
|
|
|
// NEXT hit. Note, you might think you could check auto-continue
|
|
|
|
|
// before the condition, and not evaluate the condition if it says
|
|
|
|
|
// to continue. But failing the condition means the breakpoint was
|
|
|
|
|
// effectively NOT HIT. So these two states are different.
|
|
|
|
|
bool auto_continue_says_stop = true;
|
|
|
|
|
if (bp_loc_sp->IsAutoContinue())
|
|
|
|
|
{
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"Continuing breakpoint %s as AutoContinue was set.",
|
|
|
|
|
loc_desc.GetData());
|
2017-08-03 18:13:24 +00:00
|
|
|
// We want this stop reported, so you will know we auto-continued
|
|
|
|
|
// but only for external breakpoints:
|
2023-01-25 10:50:02 +03:00
|
|
|
if (!bp_loc_sp->GetBreakpoint().IsInternal())
|
2017-08-03 18:13:24 +00:00
|
|
|
thread_sp->SetShouldReportStop(eVoteYes);
|
|
|
|
|
auto_continue_says_stop = false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool callback_says_stop = true;
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2015-10-23 18:39:37 +00:00
|
|
|
// FIXME: For now the callbacks have to run in async mode - the
|
|
|
|
|
// first time we restart we need
|
|
|
|
|
// to get out of there. So set it here.
|
|
|
|
|
// When we figure out how to nest breakpoint hits then this will
|
2013-04-29 23:30:46 +00:00
|
|
|
// change.
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2021-03-22 18:41:12 -07:00
|
|
|
// Don't run async callbacks in PerformAction. They have already
|
|
|
|
|
// been taken into account with async_should_stop.
|
|
|
|
|
if (!bp_loc_sp->IsCallbackSynchronous()) {
|
|
|
|
|
Debugger &debugger = thread_sp->CalculateTarget()->GetDebugger();
|
|
|
|
|
bool old_async = debugger.GetAsyncExecution();
|
|
|
|
|
debugger.SetAsyncExecution(true);
|
2013-04-29 23:30:46 +00:00
|
|
|
|
2021-03-22 18:41:12 -07:00
|
|
|
callback_says_stop = bp_loc_sp->InvokeCallback(&context);
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2021-03-22 18:41:12 -07:00
|
|
|
debugger.SetAsyncExecution(old_async);
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2021-03-22 18:41:12 -07:00
|
|
|
if (callback_says_stop && auto_continue_says_stop)
|
|
|
|
|
m_should_stop = true;
|
|
|
|
|
else
|
|
|
|
|
actually_said_continue = true;
|
|
|
|
|
}
|
2021-10-27 18:33:17 -07:00
|
|
|
|
2023-01-25 10:50:02 +03:00
|
|
|
if (m_should_stop && !bp_loc_sp->GetBreakpoint().IsInternal())
|
|
|
|
|
all_stopping_locs_internal = false;
|
|
|
|
|
|
2013-04-29 23:30:46 +00:00
|
|
|
// If we are going to stop for this breakpoint, then remove the
|
|
|
|
|
// breakpoint.
|
|
|
|
|
if (callback_says_stop && bp_loc_sp &&
|
2015-04-23 00:28:25 +00:00
|
|
|
bp_loc_sp->GetBreakpoint().IsOneShot()) {
|
2014-04-04 04:06:10 +00:00
|
|
|
thread_sp->GetProcess()->GetTarget().RemoveBreakpointByID(
|
2013-04-29 23:30:46 +00:00
|
|
|
bp_loc_sp->GetBreakpoint().GetID());
|
|
|
|
|
}
|
2018-04-30 16:49:04 +00:00
|
|
|
// Also make sure that the callback hasn't continued the target. If
|
|
|
|
|
// it did, when we'll set m_should_start to false and get out of
|
2016-09-06 20:57:50 +00:00
|
|
|
// here.
|
2013-04-29 23:30:46 +00:00
|
|
|
if (HasTargetRunSinceMe()) {
|
|
|
|
|
m_should_stop = false;
|
2021-03-22 18:41:12 -07:00
|
|
|
actually_said_continue = true;
|
2013-04-29 23:30:46 +00:00
|
|
|
break;
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2021-03-22 18:41:12 -07:00
|
|
|
// At this point if nobody actually told us to continue, we should
|
|
|
|
|
// give the async breakpoint callback a chance to weigh in:
|
|
|
|
|
if (!actually_said_continue && !m_should_stop) {
|
|
|
|
|
m_should_stop = async_should_stop;
|
|
|
|
|
}
|
2010-08-10 00:59:59 +00:00
|
|
|
}
|
2013-04-29 23:30:46 +00:00
|
|
|
// We've figured out what this stop wants to do, so mark it as valid so
|
|
|
|
|
// we don't compute it again.
|
|
|
|
|
m_should_stop_is_valid = true;
|
2016-09-06 20:57:50 +00:00
|
|
|
} else {
|
2013-04-29 23:30:46 +00:00
|
|
|
m_should_stop = true;
|
|
|
|
|
m_should_stop_is_valid = true;
|
2022-06-28 18:06:30 -07:00
|
|
|
actually_hit_any_locations = true;
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log_process(GetLog(LLDBLog::Process));
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log_process,
|
|
|
|
|
"Process::%s could not find breakpoint site id: %" PRId64
|
|
|
|
|
"...",
|
|
|
|
|
__FUNCTION__, m_value);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2017-02-15 11:42:47 +00:00
|
|
|
|
2023-01-25 10:50:02 +03:00
|
|
|
if ((!m_should_stop || all_stopping_locs_internal) &&
|
2018-12-15 00:15:33 +00:00
|
|
|
thread_sp->CompletedPlanOverridesBreakpoint()) {
|
|
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// Override should_stop decision when we have completed step plan
|
|
|
|
|
// additionally to the breakpoint
|
2017-02-15 11:42:47 +00:00
|
|
|
m_should_stop = true;
|
2021-10-27 18:33:17 -07:00
|
|
|
|
2019-08-15 21:37:52 +00:00
|
|
|
// We know we're stopping for a completed plan and we don't want to
|
|
|
|
|
// show the breakpoint stop, so compute the public stop info immediately
|
|
|
|
|
// here.
|
|
|
|
|
thread_sp->CalculatePublicStopInfo();
|
2022-06-28 18:06:30 -07:00
|
|
|
} else if (!actually_hit_any_locations) {
|
|
|
|
|
// In the end, we didn't actually have any locations that passed their
|
|
|
|
|
// "was I hit" checks. So say we aren't stopped.
|
|
|
|
|
GetThread()->ResetStopInfo();
|
|
|
|
|
LLDB_LOGF(log, "Process::%s all locations failed condition checks.",
|
|
|
|
|
__FUNCTION__);
|
2017-02-15 11:42:47 +00:00
|
|
|
}
|
|
|
|
|
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"Process::%s returning from action with m_should_stop: %d.",
|
|
|
|
|
__FUNCTION__, m_should_stop);
|
2010-08-10 00:59:59 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2010-08-04 01:40:35 +00:00
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
bool m_should_stop;
|
|
|
|
|
bool m_should_stop_is_valid;
|
2011-02-08 05:20:59 +00:00
|
|
|
bool m_should_perform_action; // Since we are trying to preserve the "state"
|
|
|
|
|
// of the system even if we run functions
|
|
|
|
|
// etc. behind the users backs, we need to make sure we only REALLY perform
|
|
|
|
|
// the action once.
|
2011-10-28 01:12:19 +00:00
|
|
|
lldb::addr_t m_address; // We use this to capture the breakpoint site address
|
|
|
|
|
// when we create the StopInfo,
|
|
|
|
|
// in case somebody deletes it between the time the StopInfo is made and the
|
|
|
|
|
// description is asked for.
|
2012-10-05 19:16:31 +00:00
|
|
|
lldb::break_id_t m_break_id;
|
2022-06-16 11:46:25 -07:00
|
|
|
bool m_was_all_internal;
|
2012-10-05 19:16:31 +00:00
|
|
|
bool m_was_one_shot;
|
2010-08-04 01:40:35 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
// StopInfoWatchpoint
|
|
|
|
|
|
|
|
|
|
class StopInfoWatchpoint : public StopInfo {
|
|
|
|
|
public:
|
2012-11-10 02:08:14 +00:00
|
|
|
// Make sure watchpoint is properly disabled and subsequently enabled while
|
|
|
|
|
// performing watchpoint actions.
|
|
|
|
|
class WatchpointSentry {
|
|
|
|
|
public:
|
2021-10-27 18:33:17 -07:00
|
|
|
WatchpointSentry(ProcessSP p_sp, WatchpointSP w_sp) : process_sp(p_sp),
|
2016-10-25 20:34:32 +00:00
|
|
|
watchpoint_sp(w_sp) {
|
|
|
|
|
if (process_sp && watchpoint_sp) {
|
2012-12-18 02:03:49 +00:00
|
|
|
const bool notify = false;
|
2016-10-25 20:34:32 +00:00
|
|
|
watchpoint_sp->TurnOnEphemeralMode();
|
[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(watchpoint_sp, notify);
|
2016-10-25 20:34:32 +00:00
|
|
|
process_sp->AddPreResumeAction(SentryPreResumeAction, this);
|
2012-11-10 02:08:14 +00:00
|
|
|
}
|
|
|
|
|
}
|
2021-10-27 18:33:17 -07:00
|
|
|
|
2016-10-25 20:34:32 +00:00
|
|
|
void DoReenable() {
|
|
|
|
|
if (process_sp && watchpoint_sp) {
|
|
|
|
|
bool was_disabled = watchpoint_sp->IsDisabledDuringEphemeralMode();
|
|
|
|
|
watchpoint_sp->TurnOffEphemeralMode();
|
|
|
|
|
const bool notify = false;
|
|
|
|
|
if (was_disabled) {
|
[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(watchpoint_sp, notify);
|
2016-10-25 20:34:32 +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
|
|
|
process_sp->EnableWatchpoint(watchpoint_sp, notify);
|
2012-11-10 02:08:14 +00:00
|
|
|
}
|
|
|
|
|
}
|
2010-08-04 01:40:35 +00:00
|
|
|
}
|
2021-10-27 18:33:17 -07:00
|
|
|
|
2016-10-25 20:34:32 +00:00
|
|
|
~WatchpointSentry() {
|
|
|
|
|
DoReenable();
|
|
|
|
|
if (process_sp)
|
|
|
|
|
process_sp->ClearPreResumeAction(SentryPreResumeAction, this);
|
|
|
|
|
}
|
2021-10-27 18:33:17 -07:00
|
|
|
|
2016-10-25 20:34:32 +00:00
|
|
|
static bool SentryPreResumeAction(void *sentry_void) {
|
|
|
|
|
WatchpointSentry *sentry = (WatchpointSentry *) sentry_void;
|
|
|
|
|
sentry->DoReenable();
|
|
|
|
|
return true;
|
|
|
|
|
}
|
2010-08-04 01:40:35 +00:00
|
|
|
|
2015-10-23 18:39:37 +00:00
|
|
|
private:
|
2016-10-25 20:34:32 +00:00
|
|
|
ProcessSP process_sp;
|
|
|
|
|
WatchpointSP watchpoint_sp;
|
2016-09-06 20:57:50 +00:00
|
|
|
};
|
2015-10-23 18:39:37 +00:00
|
|
|
|
2023-04-12 17:53:51 -07:00
|
|
|
StopInfoWatchpoint(Thread &thread, break_id_t watch_id, bool silently_skip_wp)
|
|
|
|
|
: StopInfo(thread, watch_id), m_silently_skip_wp(silently_skip_wp) {}
|
2010-08-04 01:40:35 +00:00
|
|
|
|
2015-10-23 18:39:37 +00:00
|
|
|
~StopInfoWatchpoint() override = default;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-10-23 18:39:37 +00:00
|
|
|
StopReason GetStopReason() const override { return eStopReasonWatchpoint; }
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-10-23 18:39:37 +00:00
|
|
|
const char *GetDescription() override {
|
2012-11-10 02:08:14 +00:00
|
|
|
if (m_description.empty()) {
|
|
|
|
|
StreamString strm;
|
2012-11-29 21:49:15 +00:00
|
|
|
strm.Printf("watchpoint %" PRIi64, m_value);
|
2020-01-28 20:23:46 +01:00
|
|
|
m_description = std::string(strm.GetString());
|
2012-11-10 02:08:14 +00:00
|
|
|
}
|
|
|
|
|
return m_description.c_str();
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2012-11-10 02:08:14 +00:00
|
|
|
|
|
|
|
|
protected:
|
2022-07-27 09:27:51 -07:00
|
|
|
using StopInfoWatchpointSP = std::shared_ptr<StopInfoWatchpoint>;
|
|
|
|
|
// This plan is used to orchestrate stepping over the watchpoint for
|
|
|
|
|
// architectures (e.g. ARM) that report the watch before running the watched
|
|
|
|
|
// access. This is the sort of job you have to defer to the thread plans,
|
|
|
|
|
// if you try to do it directly in the stop info and there are other threads
|
|
|
|
|
// that needed to process this stop you will have yanked control away from
|
|
|
|
|
// them and they won't behave correctly.
|
|
|
|
|
class ThreadPlanStepOverWatchpoint : public ThreadPlanStepInstruction {
|
|
|
|
|
public:
|
|
|
|
|
ThreadPlanStepOverWatchpoint(Thread &thread,
|
|
|
|
|
StopInfoWatchpointSP stop_info_sp,
|
|
|
|
|
WatchpointSP watch_sp)
|
|
|
|
|
: ThreadPlanStepInstruction(thread, false, true, eVoteNoOpinion,
|
|
|
|
|
eVoteNoOpinion),
|
|
|
|
|
m_stop_info_sp(stop_info_sp), m_watch_sp(watch_sp) {
|
|
|
|
|
assert(watch_sp);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool DoWillResume(lldb::StateType resume_state,
|
|
|
|
|
bool current_plan) override {
|
|
|
|
|
if (resume_state == eStateSuspended)
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
if (!m_did_disable_wp) {
|
[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
|
|
|
GetThread().GetProcess()->DisableWatchpoint(m_watch_sp, false);
|
2022-07-27 09:27:51 -07:00
|
|
|
m_did_disable_wp = true;
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool DoPlanExplainsStop(Event *event_ptr) override {
|
|
|
|
|
if (ThreadPlanStepInstruction::DoPlanExplainsStop(event_ptr))
|
|
|
|
|
return true;
|
|
|
|
|
StopInfoSP stop_info_sp = GetThread().GetPrivateStopInfo();
|
|
|
|
|
// lldb-server resets the stop info for threads that didn't get to run,
|
|
|
|
|
// so we might have not gotten to run, but still have a watchpoint stop
|
|
|
|
|
// reason, in which case this will indeed be for us.
|
|
|
|
|
if (stop_info_sp
|
|
|
|
|
&& stop_info_sp->GetStopReason() == eStopReasonWatchpoint)
|
|
|
|
|
return true;
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void DidPop() override {
|
|
|
|
|
// Don't artifically keep the watchpoint alive.
|
|
|
|
|
m_watch_sp.reset();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool ShouldStop(Event *event_ptr) override {
|
|
|
|
|
bool should_stop = ThreadPlanStepInstruction::ShouldStop(event_ptr);
|
|
|
|
|
bool plan_done = MischiefManaged();
|
|
|
|
|
if (plan_done) {
|
|
|
|
|
m_stop_info_sp->SetStepOverPlanComplete();
|
|
|
|
|
GetThread().SetStopInfo(m_stop_info_sp);
|
|
|
|
|
ResetWatchpoint();
|
|
|
|
|
}
|
|
|
|
|
return should_stop;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool ShouldRunBeforePublicStop() override {
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
protected:
|
|
|
|
|
void ResetWatchpoint() {
|
|
|
|
|
if (!m_did_disable_wp)
|
|
|
|
|
return;
|
|
|
|
|
m_did_disable_wp = true;
|
[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
|
|
|
GetThread().GetProcess()->EnableWatchpoint(m_watch_sp, true);
|
2022-07-27 09:27:51 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
StopInfoWatchpointSP m_stop_info_sp;
|
|
|
|
|
WatchpointSP m_watch_sp;
|
|
|
|
|
bool m_did_disable_wp = false;
|
|
|
|
|
};
|
|
|
|
|
|
2015-10-23 18:39:37 +00:00
|
|
|
bool ShouldStopSynchronous(Event *event_ptr) override {
|
2022-07-27 09:27:51 -07:00
|
|
|
// If we are running our step-over the watchpoint plan, stop if it's done
|
|
|
|
|
// and continue if it's not:
|
2022-07-18 17:38:43 -07:00
|
|
|
if (m_should_stop_is_valid)
|
|
|
|
|
return m_should_stop;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2022-07-27 09:27:51 -07:00
|
|
|
// If we are running our step over plan, then stop here and let the regular
|
|
|
|
|
// ShouldStop figure out what we should do: Otherwise, give our plan
|
|
|
|
|
// more time to get run:
|
|
|
|
|
if (m_using_step_over_plan)
|
|
|
|
|
return m_step_over_plan_complete;
|
|
|
|
|
|
|
|
|
|
Log *log = GetLog(LLDBLog::Process);
|
2013-04-29 23:30:46 +00:00
|
|
|
ThreadSP thread_sp(m_thread_wp.lock());
|
2022-07-27 09:27:51 -07:00
|
|
|
assert(thread_sp);
|
|
|
|
|
|
|
|
|
|
if (thread_sp->GetTemporaryResumeState() == eStateSuspended) {
|
|
|
|
|
// This is the second firing of a watchpoint so don't process it again.
|
|
|
|
|
LLDB_LOG(log, "We didn't run but stopped with a StopInfoWatchpoint, we "
|
|
|
|
|
"have already handled this one, don't do it again.");
|
|
|
|
|
m_should_stop = false;
|
|
|
|
|
m_should_stop_is_valid = true;
|
|
|
|
|
return m_should_stop;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
WatchpointSP wp_sp(
|
|
|
|
|
thread_sp->CalculateTarget()->GetWatchpointList().FindByID(GetValue()));
|
|
|
|
|
// If we can no longer find the watchpoint, we just have to stop:
|
|
|
|
|
if (!wp_sp) {
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2022-07-27 09:27:51 -07:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"Process::%s could not find watchpoint location id: %" PRId64
|
|
|
|
|
"...",
|
|
|
|
|
__FUNCTION__, GetValue());
|
|
|
|
|
|
|
|
|
|
m_should_stop = true;
|
|
|
|
|
m_should_stop_is_valid = true;
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ExecutionContext exe_ctx(thread_sp->GetStackFrameAtIndex(0));
|
|
|
|
|
StoppointCallbackContext context(event_ptr, exe_ctx, true);
|
|
|
|
|
m_should_stop = wp_sp->ShouldStop(&context);
|
|
|
|
|
if (!m_should_stop) {
|
|
|
|
|
// This won't happen at present because we only allow one watchpoint per
|
|
|
|
|
// watched range. So we won't stop at a watched address with a disabled
|
|
|
|
|
// watchpoint. If we start allowing overlapping watchpoints, then we
|
|
|
|
|
// will have to make watchpoints be real "WatchpointSite" and delegate to
|
|
|
|
|
// all the watchpoints sharing the site. In that case, the code below
|
|
|
|
|
// would be the right thing to do.
|
|
|
|
|
m_should_stop_is_valid = true;
|
|
|
|
|
return m_should_stop;
|
|
|
|
|
}
|
|
|
|
|
// If this is a system where we need to execute the watchpoint by hand
|
|
|
|
|
// after the hit, queue a thread plan to do that, and then say not to stop.
|
|
|
|
|
// Otherwise, let the async action figure out whether the watchpoint should
|
|
|
|
|
// stop
|
|
|
|
|
|
|
|
|
|
ProcessSP process_sp = exe_ctx.GetProcessSP();
|
2023-02-14 11:29:19 -08:00
|
|
|
bool wp_triggers_after = process_sp->GetWatchpointReportedAfter();
|
2022-07-27 09:27:51 -07:00
|
|
|
|
|
|
|
|
if (!wp_triggers_after) {
|
|
|
|
|
// We have to step over the watchpoint before we know what to do:
|
|
|
|
|
StopInfoWatchpointSP me_as_siwp_sp
|
|
|
|
|
= std::static_pointer_cast<StopInfoWatchpoint>(shared_from_this());
|
|
|
|
|
ThreadPlanSP step_over_wp_sp(new ThreadPlanStepOverWatchpoint(
|
|
|
|
|
*(thread_sp.get()), me_as_siwp_sp, wp_sp));
|
2023-03-20 16:11:00 -07:00
|
|
|
// When this plan is done we want to stop, so set this as a Controlling
|
|
|
|
|
// plan.
|
|
|
|
|
step_over_wp_sp->SetIsControllingPlan(true);
|
|
|
|
|
step_over_wp_sp->SetOkayToDiscard(false);
|
|
|
|
|
|
2022-07-27 09:27:51 -07:00
|
|
|
Status error;
|
|
|
|
|
error = thread_sp->QueueThreadPlan(step_over_wp_sp, false);
|
|
|
|
|
// If we couldn't push the thread plan, just stop here:
|
|
|
|
|
if (!error.Success()) {
|
|
|
|
|
LLDB_LOGF(log, "Could not push our step over watchpoint plan: %s",
|
|
|
|
|
error.AsCString());
|
2022-07-12 18:34:24 -07:00
|
|
|
|
2022-07-18 17:38:43 -07:00
|
|
|
m_should_stop = true;
|
2022-07-27 09:27:51 -07:00
|
|
|
m_should_stop_is_valid = true;
|
|
|
|
|
return true;
|
|
|
|
|
} else {
|
|
|
|
|
// Otherwise, don't set m_should_stop, we don't know that yet. Just
|
|
|
|
|
// say we should continue, and tell the thread we really should do so:
|
|
|
|
|
thread_sp->SetShouldRunBeforePublicStop(true);
|
|
|
|
|
m_using_step_over_plan = true;
|
|
|
|
|
return false;
|
2022-07-18 17:38:43 -07:00
|
|
|
}
|
2022-07-27 09:27:51 -07:00
|
|
|
} else {
|
|
|
|
|
// We didn't have to do anything special
|
|
|
|
|
m_should_stop_is_valid = true;
|
|
|
|
|
return m_should_stop;
|
2022-07-12 18:34:24 -07:00
|
|
|
}
|
2022-07-27 09:27:51 -07:00
|
|
|
|
2022-07-18 17:38:43 -07:00
|
|
|
return m_should_stop;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2015-10-23 18:39:37 +00:00
|
|
|
bool ShouldStop(Event *event_ptr) override {
|
2018-04-30 16:49:04 +00:00
|
|
|
// This just reports the work done by PerformAction or the synchronous
|
|
|
|
|
// stop. It should only ever get called after they have had a chance to
|
|
|
|
|
// run.
|
2013-02-22 21:23:43 +00:00
|
|
|
assert(m_should_stop_is_valid);
|
2011-09-21 22:47:15 +00:00
|
|
|
return m_should_stop;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2015-10-23 18:39:37 +00:00
|
|
|
void PerformAction(Event *event_ptr) override {
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Watchpoints);
|
2011-10-17 18:58:00 +00:00
|
|
|
// We're going to calculate if we should stop or not in some way during the
|
2018-04-30 16:49:04 +00:00
|
|
|
// course of this code. Also by default we're going to stop, so set that
|
|
|
|
|
// here.
|
2013-04-29 23:30:46 +00:00
|
|
|
m_should_stop = true;
|
2021-10-27 18:33:17 -07:00
|
|
|
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-04-29 23:30:46 +00:00
|
|
|
ThreadSP thread_sp(m_thread_wp.lock());
|
|
|
|
|
if (thread_sp) {
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-04-29 23:30:46 +00:00
|
|
|
WatchpointSP wp_sp(
|
|
|
|
|
thread_sp->CalculateTarget()->GetWatchpointList().FindByID(
|
2021-10-27 18:33:17 -07:00
|
|
|
GetValue()));
|
2013-04-29 23:30:46 +00:00
|
|
|
if (wp_sp) {
|
2022-07-18 17:38:43 -07:00
|
|
|
// This sentry object makes sure the current watchpoint is disabled
|
|
|
|
|
// while performing watchpoint actions, and it is then enabled after we
|
|
|
|
|
// are finished.
|
2022-07-27 09:27:51 -07:00
|
|
|
ExecutionContext exe_ctx(thread_sp->GetStackFrameAtIndex(0));
|
|
|
|
|
ProcessSP process_sp = exe_ctx.GetProcessSP();
|
|
|
|
|
|
2016-10-25 20:34:32 +00:00
|
|
|
WatchpointSentry sentry(process_sp, wp_sp);
|
|
|
|
|
|
2023-04-12 17:53:51 -07:00
|
|
|
if (m_silently_skip_wp) {
|
|
|
|
|
m_should_stop = false;
|
2023-07-20 15:14:07 -07:00
|
|
|
wp_sp->UndoHitCount();
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2011-09-21 22:47:15 +00:00
|
|
|
|
2022-07-27 09:27:51 -07:00
|
|
|
if (wp_sp->GetHitCount() <= wp_sp->GetIgnoreCount()) {
|
2015-08-13 03:44:09 +00:00
|
|
|
m_should_stop = false;
|
2022-07-27 09:27:51 -07:00
|
|
|
m_should_stop_is_valid = true;
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2016-10-25 20:34:32 +00:00
|
|
|
Debugger &debugger = exe_ctx.GetTargetRef().GetDebugger();
|
|
|
|
|
|
2016-02-18 18:52:47 +00:00
|
|
|
if (m_should_stop && wp_sp->GetConditionText() != nullptr) {
|
2013-04-29 23:30:46 +00:00
|
|
|
// We need to make sure the user sees any parse errors in their
|
2016-11-08 04:52:16 +00:00
|
|
|
// condition, so we'll hook the constructor errors up to the
|
|
|
|
|
// debugger's Async I/O.
|
2014-05-05 02:26:40 +00:00
|
|
|
ExpressionResults result_code;
|
2013-11-04 19:35:17 +00:00
|
|
|
EvaluateExpressionOptions expr_options;
|
|
|
|
|
expr_options.SetUnwindOnError(true);
|
|
|
|
|
expr_options.SetIgnoreBreakpoints(true);
|
2013-04-29 23:30:46 +00:00
|
|
|
ValueObjectSP result_value_sp;
|
2017-05-12 04:51:55 +00:00
|
|
|
Status error;
|
2016-02-18 18:52:47 +00:00
|
|
|
result_code = UserExpression::Evaluate(
|
2016-11-08 04:52:16 +00:00
|
|
|
exe_ctx, expr_options, wp_sp->GetConditionText(),
|
|
|
|
|
llvm::StringRef(), result_value_sp, error);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2014-05-05 02:47:44 +00:00
|
|
|
if (result_code == eExpressionCompleted) {
|
2013-04-29 23:30:46 +00:00
|
|
|
if (result_value_sp) {
|
|
|
|
|
Scalar scalar_value;
|
|
|
|
|
if (result_value_sp->ResolveValue(scalar_value)) {
|
|
|
|
|
if (scalar_value.ULongLong(1) == 0) {
|
2022-07-27 09:27:51 -07:00
|
|
|
// The condition failed, which we consider "not having hit
|
|
|
|
|
// the watchpoint" so undo the hit count here.
|
|
|
|
|
wp_sp->UndoHitCount();
|
2015-08-13 03:44:09 +00:00
|
|
|
m_should_stop = false;
|
2016-09-06 20:57:50 +00:00
|
|
|
} else
|
2013-04-29 23:30:46 +00:00
|
|
|
m_should_stop = true;
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"Condition successfully evaluated, result is %s.\n",
|
|
|
|
|
m_should_stop ? "true" : "false");
|
2016-09-06 20:57:50 +00:00
|
|
|
} else {
|
2013-04-29 23:30:46 +00:00
|
|
|
m_should_stop = true;
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(
|
|
|
|
|
log,
|
|
|
|
|
"Failed to get an integer result from the expression.");
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2013-04-29 23:30:46 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
} else {
|
2022-03-16 22:38:39 -07:00
|
|
|
const char *err_str = error.AsCString("<unknown error>");
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log, "Error evaluating condition: \"%s\"\n", err_str);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2022-03-16 22:38:39 -07:00
|
|
|
StreamString strm;
|
|
|
|
|
strm << "stopped due to an error evaluating condition of "
|
|
|
|
|
"watchpoint ";
|
|
|
|
|
wp_sp->GetDescription(&strm, eDescriptionLevelBrief);
|
|
|
|
|
strm << ": \"" << wp_sp->GetConditionText() << "\"\n";
|
|
|
|
|
strm << err_str;
|
|
|
|
|
|
|
|
|
|
Debugger::ReportError(strm.GetString().str(),
|
|
|
|
|
exe_ctx.GetTargetRef().GetDebugger().GetID());
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2011-09-21 22:47:15 +00:00
|
|
|
}
|
2012-08-21 22:06:34 +00:00
|
|
|
|
2013-04-29 23:30:46 +00:00
|
|
|
// If the condition says to stop, we run the callback to further decide
|
|
|
|
|
// whether to stop.
|
|
|
|
|
if (m_should_stop) {
|
2016-10-25 20:34:32 +00:00
|
|
|
// FIXME: For now the callbacks have to run in async mode - the
|
|
|
|
|
// first time we restart we need
|
|
|
|
|
// to get out of there. So set it here.
|
|
|
|
|
// When we figure out how to nest watchpoint hits then this will
|
|
|
|
|
// change.
|
|
|
|
|
|
|
|
|
|
bool old_async = debugger.GetAsyncExecution();
|
|
|
|
|
debugger.SetAsyncExecution(true);
|
2021-10-27 18:33:17 -07:00
|
|
|
|
2013-04-29 23:30:46 +00:00
|
|
|
StoppointCallbackContext context(event_ptr, exe_ctx, false);
|
|
|
|
|
bool stop_requested = wp_sp->InvokeCallback(&context);
|
2021-10-27 18:33:17 -07:00
|
|
|
|
2016-10-25 20:34:32 +00:00
|
|
|
debugger.SetAsyncExecution(old_async);
|
2021-10-27 18:33:17 -07:00
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// Also make sure that the callback hasn't continued the target. If
|
|
|
|
|
// it did, when we'll set m_should_stop to false and get out of here.
|
2013-04-29 23:30:46 +00:00
|
|
|
if (HasTargetRunSinceMe())
|
2013-07-02 21:12:44 +00:00
|
|
|
m_should_stop = false;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-07-02 21:12:44 +00:00
|
|
|
if (m_should_stop && !stop_requested) {
|
2013-07-18 21:48:26 +00:00
|
|
|
// We have been vetoed by the callback mechanism.
|
|
|
|
|
m_should_stop = false;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2013-04-29 23:30:46 +00:00
|
|
|
}
|
2023-09-21 10:21:53 +00:00
|
|
|
|
|
|
|
|
// Don't stop if the watched region value is unmodified, and
|
|
|
|
|
// this is a Modify-type watchpoint.
|
[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 (m_should_stop && !wp_sp->WatchedValueReportable(exe_ctx)) {
|
|
|
|
|
wp_sp->UndoHitCount();
|
2023-09-21 10:21:53 +00:00
|
|
|
m_should_stop = false;
|
[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
|
|
|
}
|
2023-09-21 10:21:53 +00:00
|
|
|
|
2015-08-13 03:44:09 +00:00
|
|
|
// Finally, if we are going to stop, print out the new & old values:
|
|
|
|
|
if (m_should_stop) {
|
|
|
|
|
wp_sp->CaptureWatchedValue(exe_ctx);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-08-13 03:44:09 +00:00
|
|
|
Debugger &debugger = exe_ctx.GetTargetRef().GetDebugger();
|
|
|
|
|
StreamSP output_sp = debugger.GetAsyncOutputStream();
|
[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 (wp_sp->DumpSnapshots(output_sp.get())) {
|
|
|
|
|
output_sp->EOL();
|
|
|
|
|
output_sp->Flush();
|
|
|
|
|
}
|
2015-10-06 05:25:17 +00:00
|
|
|
}
|
|
|
|
|
|
2013-04-29 23:30:46 +00:00
|
|
|
} else {
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log_process(GetLog(LLDBLog::Process));
|
2011-10-17 18:58:00 +00:00
|
|
|
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log_process,
|
|
|
|
|
"Process::%s could not find watchpoint id: %" PRId64 "...",
|
|
|
|
|
__FUNCTION__, m_value);
|
2012-08-09 23:10:57 +00:00
|
|
|
}
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"Process::%s returning from action with m_should_stop: %d.",
|
|
|
|
|
__FUNCTION__, m_should_stop);
|
2013-04-29 23:30:46 +00:00
|
|
|
|
|
|
|
|
m_should_stop_is_valid = true;
|
2011-10-17 18:58:00 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2010-08-04 01:40:35 +00:00
|
|
|
private:
|
2022-07-27 09:27:51 -07:00
|
|
|
void SetStepOverPlanComplete() {
|
|
|
|
|
assert(m_using_step_over_plan);
|
|
|
|
|
m_step_over_plan_complete = true;
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-14 13:32:03 -07:00
|
|
|
bool m_should_stop = false;
|
|
|
|
|
bool m_should_stop_is_valid = false;
|
2023-04-12 17:53:51 -07:00
|
|
|
// A false watchpoint hit has happened -
|
|
|
|
|
// the thread stopped with a watchpoint
|
|
|
|
|
// hit notification, but the watched region
|
|
|
|
|
// was not actually accessed (as determined
|
|
|
|
|
// by the gdb stub we're talking to).
|
|
|
|
|
// Continue past this watchpoint without
|
|
|
|
|
// notifying the user; on some targets this
|
|
|
|
|
// may mean disable wp, instruction step,
|
|
|
|
|
// re-enable wp, continue.
|
|
|
|
|
// On others, just continue.
|
|
|
|
|
bool m_silently_skip_wp = false;
|
2022-07-27 09:27:51 -07:00
|
|
|
bool m_step_over_plan_complete = false;
|
|
|
|
|
bool m_using_step_over_plan = false;
|
2010-08-04 01:40:35 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
// StopInfoUnixSignal
|
|
|
|
|
|
|
|
|
|
class StopInfoUnixSignal : public StopInfo {
|
|
|
|
|
public:
|
2023-03-14 11:52:48 +00:00
|
|
|
StopInfoUnixSignal(Thread &thread, int signo, const char *description,
|
|
|
|
|
std::optional<int> code)
|
|
|
|
|
: StopInfo(thread, signo), m_code(code) {
|
Report inferior SIGSEGV as a signal instead of an exception on linux
Summary:
Previously, we reported inferior receiving SIGSEGV (or SIGILL, SIGFPE, SIGBUS) as an "exception"
to LLDB, presumably to match OSX behaviour. Beside the fact that we were basically lying to the
user, this was also causing problems with inferiors which handle SIGSEGV by themselves, since
LLDB was unable to reinject this signal back into the inferior.
This commit changes LLGS to report SIGSEGV as a signal. This has necessitated some changes in the
test-suite, which had previously used eStopReasonException to locate threads that crashed. Now it
uses platform-specific logic, which in the case of linux searches for eStopReasonSignaled with
signal=SIGSEGV.
I have also added the ability to set the description of StopInfoUnixSignal using the description
field of the gdb-remote packet. The linux stub uses this to display additional information about
the segfault (invalid address, address access protected, etc.).
Test Plan: All tests pass on linux and osx.
Reviewers: ovyalov, clayborg, emaste
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D10057
llvm-svn: 238549
2015-05-29 10:13:03 +00:00
|
|
|
SetDescription(description);
|
2010-08-04 01:40:35 +00:00
|
|
|
}
|
|
|
|
|
|
2015-10-23 18:39:37 +00:00
|
|
|
~StopInfoUnixSignal() override = default;
|
2010-08-04 01:40:35 +00:00
|
|
|
|
2015-07-14 01:09:28 +00:00
|
|
|
StopReason GetStopReason() const override { return eStopReasonSignal; }
|
2013-02-09 01:29:05 +00:00
|
|
|
|
2015-10-23 18:39:37 +00:00
|
|
|
bool ShouldStopSynchronous(Event *event_ptr) override {
|
2013-04-29 23:30:46 +00:00
|
|
|
ThreadSP thread_sp(m_thread_wp.lock());
|
|
|
|
|
if (thread_sp)
|
2015-07-14 01:09:28 +00:00
|
|
|
return thread_sp->GetProcess()->GetUnixSignals()->GetShouldStop(m_value);
|
2013-04-29 23:30:46 +00:00
|
|
|
return false;
|
2010-08-04 01:40:35 +00:00
|
|
|
}
|
2015-10-23 18:39:37 +00:00
|
|
|
|
|
|
|
|
bool ShouldStop(Event *event_ptr) override {
|
2013-04-29 23:30:46 +00:00
|
|
|
ThreadSP thread_sp(m_thread_wp.lock());
|
|
|
|
|
if (thread_sp)
|
2016-02-18 18:52:47 +00:00
|
|
|
return thread_sp->GetProcess()->GetUnixSignals()->GetShouldStop(m_value);
|
2013-04-29 23:30:46 +00:00
|
|
|
return false;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2010-08-04 01:40:35 +00:00
|
|
|
// If should stop returns false, check if we should notify of this event
|
2015-10-23 18:39:37 +00:00
|
|
|
bool DoShouldNotify(Event *event_ptr) override {
|
2013-04-29 23:30:46 +00:00
|
|
|
ThreadSP thread_sp(m_thread_wp.lock());
|
|
|
|
|
if (thread_sp) {
|
2015-07-14 01:09:28 +00:00
|
|
|
bool should_notify =
|
|
|
|
|
thread_sp->GetProcess()->GetUnixSignals()->GetShouldNotify(m_value);
|
2013-04-29 23:30:46 +00:00
|
|
|
if (should_notify) {
|
|
|
|
|
StreamString strm;
|
2023-08-17 10:57:05 -07:00
|
|
|
strm.Format(
|
|
|
|
|
"thread {0:d} received signal: {1}", thread_sp->GetIndexID(),
|
|
|
|
|
thread_sp->GetProcess()->GetUnixSignals()->GetSignalAsStringRef(
|
2015-07-14 01:09:28 +00:00
|
|
|
m_value));
|
2013-04-29 23:30:46 +00:00
|
|
|
Process::ProcessEventData::AddRestartedReason(event_ptr,
|
|
|
|
|
strm.GetData());
|
|
|
|
|
}
|
|
|
|
|
return should_notify;
|
2010-08-04 01:40:35 +00:00
|
|
|
}
|
2013-04-29 23:30:46 +00:00
|
|
|
return true;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2015-10-23 18:39:37 +00:00
|
|
|
void WillResume(lldb::StateType resume_state) override {
|
2013-04-29 23:30:46 +00:00
|
|
|
ThreadSP thread_sp(m_thread_wp.lock());
|
|
|
|
|
if (thread_sp) {
|
2016-02-18 18:52:47 +00:00
|
|
|
if (!thread_sp->GetProcess()->GetUnixSignals()->GetShouldSuppress(
|
|
|
|
|
m_value))
|
2013-04-29 23:30:46 +00:00
|
|
|
thread_sp->SetResumeSignal(m_value);
|
2010-08-04 01:40:35 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2015-10-23 18:39:37 +00:00
|
|
|
const char *GetDescription() override {
|
2010-08-04 01:40:35 +00:00
|
|
|
if (m_description.empty()) {
|
2013-04-29 23:30:46 +00:00
|
|
|
ThreadSP thread_sp(m_thread_wp.lock());
|
|
|
|
|
if (thread_sp) {
|
2023-03-14 11:52:48 +00:00
|
|
|
UnixSignalsSP unix_signals = thread_sp->GetProcess()->GetUnixSignals();
|
2013-04-29 23:30:46 +00:00
|
|
|
StreamString strm;
|
2023-03-14 11:52:48 +00:00
|
|
|
strm << "signal ";
|
|
|
|
|
|
|
|
|
|
std::string signal_name =
|
|
|
|
|
unix_signals->GetSignalDescription(m_value, m_code);
|
|
|
|
|
if (signal_name.size())
|
|
|
|
|
strm << signal_name;
|
2013-04-29 23:30:46 +00:00
|
|
|
else
|
2023-03-14 11:52:48 +00:00
|
|
|
strm.Printf("%" PRIi64, m_value);
|
|
|
|
|
|
2020-01-28 20:23:46 +01:00
|
|
|
m_description = std::string(strm.GetString());
|
2010-08-04 01:40:35 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return m_description.c_str();
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2023-03-14 11:52:48 +00:00
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
// In siginfo_t terms, if m_value is si_signo, m_code is si_code.
|
|
|
|
|
std::optional<int> m_code;
|
2010-08-04 01:40:35 +00:00
|
|
|
};
|
|
|
|
|
|
New ThreadPlanSingleThreadTimeout to resolve potential deadlock in single thread stepping (#90930)
This PR introduces a new `ThreadPlanSingleThreadTimeout` that will be
used to address potential deadlock during single-thread stepping.
While debugging a target with a non-trivial number of threads (around
5000 threads in one example target), we noticed that a simple step over
can take as long as 10 seconds. Enabling single-thread stepping mode
significantly reduces the stepping time to around 3 seconds. However,
this can introduce deadlock if we try to step over a method that depends
on other threads to release a lock.
To address this issue, we introduce a new
`ThreadPlanSingleThreadTimeout` that can be controlled by the
`target.process.thread.single-thread-plan-timeout` setting during
single-thread stepping mode. The concept involves counting the elapsed
time since the last internal stop to detect overall stepping progress.
Once a timeout occurs, we assume the target is not making progress due
to a potential deadlock, as mentioned above. We then send a new async
interrupt, resume all threads, and `ThreadPlanSingleThreadTimeout`
completes its task.
To support this design, the major changes made in this PR are:
1. `ThreadPlanSingleThreadTimeout` is popped during every internal stop
and reset (re-pushed) to the top of the stack (as a leaf node) during
resume. This is achieved by always returning `true` from
`ThreadPlanSingleThreadTimeout::DoPlanExplainsStop()` and
`ThreadPlanSingleThreadTimeout::MischiefManaged()`.
2. A new thread-specific async interrupt stop is introduced, which can
be detected/consumed by `ThreadPlanSingleThreadTimeout`.
3. The clearing of branch breakpoints in the range thread plan has been
moved from `DoPlanExplainsStop()` to `ShouldStop()`, as it is not
guaranteed that it will be called.
The detailed design is discussed in the RFC below:
[https://discourse.llvm.org/t/improve-single-thread-stepping/74599](https://discourse.llvm.org/t/improve-single-thread-stepping/74599)
---------
Co-authored-by: jeffreytan81 <jeffreytan@fb.com>
2024-08-05 17:26:39 -07:00
|
|
|
// StopInfoInterrupt
|
|
|
|
|
|
|
|
|
|
class StopInfoInterrupt : public StopInfo {
|
|
|
|
|
public:
|
|
|
|
|
StopInfoInterrupt(Thread &thread, int signo, const char *description)
|
|
|
|
|
: StopInfo(thread, signo) {
|
|
|
|
|
SetDescription(description);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
~StopInfoInterrupt() override = default;
|
|
|
|
|
|
|
|
|
|
StopReason GetStopReason() const override {
|
|
|
|
|
return lldb::eStopReasonInterrupt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const char *GetDescription() override {
|
|
|
|
|
if (m_description.empty()) {
|
|
|
|
|
m_description = "async interrupt";
|
|
|
|
|
}
|
|
|
|
|
return m_description.c_str();
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
2010-08-04 01:40:35 +00:00
|
|
|
// StopInfoTrace
|
|
|
|
|
|
|
|
|
|
class StopInfoTrace : public StopInfo {
|
|
|
|
|
public:
|
|
|
|
|
StopInfoTrace(Thread &thread) : StopInfo(thread, LLDB_INVALID_UID) {}
|
2015-10-23 18:39:37 +00:00
|
|
|
|
|
|
|
|
~StopInfoTrace() override = default;
|
|
|
|
|
|
|
|
|
|
StopReason GetStopReason() const override { return eStopReasonTrace; }
|
2010-08-04 01:40:35 +00:00
|
|
|
|
2015-10-23 18:39:37 +00:00
|
|
|
const char *GetDescription() override {
|
2011-06-04 01:26:29 +00:00
|
|
|
if (m_description.empty())
|
2015-10-23 18:39:37 +00:00
|
|
|
return "trace";
|
2011-06-04 01:26:29 +00:00
|
|
|
else
|
|
|
|
|
return m_description.c_str();
|
|
|
|
|
}
|
2024-10-30 09:28:38 -07:00
|
|
|
|
|
|
|
|
std::optional<uint32_t>
|
|
|
|
|
GetSuggestedStackFrameIndex(bool inlined_stack) override {
|
|
|
|
|
// Trace only knows how to adjust inlined stacks:
|
|
|
|
|
if (!inlined_stack)
|
|
|
|
|
return {};
|
|
|
|
|
|
|
|
|
|
ThreadSP thread_sp = GetThread();
|
|
|
|
|
StackFrameSP frame_0_sp = thread_sp->GetStackFrameAtIndex(0);
|
|
|
|
|
if (!frame_0_sp)
|
|
|
|
|
return {};
|
|
|
|
|
if (!frame_0_sp->IsInlined())
|
|
|
|
|
return {};
|
|
|
|
|
Block *block_ptr = frame_0_sp->GetFrameBlock();
|
|
|
|
|
if (!block_ptr)
|
|
|
|
|
return {};
|
|
|
|
|
Address pc_address = frame_0_sp->GetFrameCodeAddress();
|
|
|
|
|
AddressRange containing_range;
|
|
|
|
|
if (!block_ptr->GetRangeContainingAddress(pc_address, containing_range) ||
|
|
|
|
|
pc_address != containing_range.GetBaseAddress())
|
|
|
|
|
return {};
|
|
|
|
|
|
|
|
|
|
int num_inlined_functions = 0;
|
|
|
|
|
|
|
|
|
|
for (Block *container_ptr = block_ptr->GetInlinedParent();
|
|
|
|
|
container_ptr != nullptr;
|
|
|
|
|
container_ptr = container_ptr->GetInlinedParent()) {
|
|
|
|
|
if (!container_ptr->GetRangeContainingAddress(pc_address,
|
|
|
|
|
containing_range))
|
|
|
|
|
break;
|
|
|
|
|
if (pc_address != containing_range.GetBaseAddress())
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
num_inlined_functions++;
|
|
|
|
|
}
|
|
|
|
|
inlined_stack = true;
|
|
|
|
|
return num_inlined_functions + 1;
|
|
|
|
|
}
|
2011-06-04 01:26:29 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
// StopInfoException
|
|
|
|
|
|
|
|
|
|
class StopInfoException : public StopInfo {
|
|
|
|
|
public:
|
|
|
|
|
StopInfoException(Thread &thread, const char *description)
|
|
|
|
|
: StopInfo(thread, LLDB_INVALID_UID) {
|
|
|
|
|
if (description)
|
|
|
|
|
SetDescription(description);
|
|
|
|
|
}
|
2015-10-23 18:39:37 +00:00
|
|
|
|
|
|
|
|
~StopInfoException() override = default;
|
|
|
|
|
|
|
|
|
|
StopReason GetStopReason() const override { return eStopReasonException; }
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-10-23 18:39:37 +00:00
|
|
|
const char *GetDescription() override {
|
2011-06-04 01:26:29 +00:00
|
|
|
if (m_description.empty())
|
|
|
|
|
return "exception";
|
|
|
|
|
else
|
|
|
|
|
return m_description.c_str();
|
2010-08-04 01:40:35 +00:00
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
2020-11-09 13:36:26 -08:00
|
|
|
// StopInfoProcessorTrace
|
|
|
|
|
|
|
|
|
|
class StopInfoProcessorTrace : public StopInfo {
|
|
|
|
|
public:
|
|
|
|
|
StopInfoProcessorTrace(Thread &thread, const char *description)
|
|
|
|
|
: StopInfo(thread, LLDB_INVALID_UID) {
|
|
|
|
|
if (description)
|
|
|
|
|
SetDescription(description);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
~StopInfoProcessorTrace() override = default;
|
|
|
|
|
|
|
|
|
|
StopReason GetStopReason() const override {
|
|
|
|
|
return eStopReasonProcessorTrace;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const char *GetDescription() override {
|
|
|
|
|
if (m_description.empty())
|
|
|
|
|
return "processor trace event";
|
|
|
|
|
else
|
|
|
|
|
return m_description.c_str();
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
2010-08-04 01:40:35 +00:00
|
|
|
// StopInfoThreadPlan
|
|
|
|
|
|
|
|
|
|
class StopInfoThreadPlan : public StopInfo {
|
|
|
|
|
public:
|
2015-09-04 20:49:51 +00:00
|
|
|
StopInfoThreadPlan(ThreadPlanSP &plan_sp, ValueObjectSP &return_valobj_sp,
|
|
|
|
|
ExpressionVariableSP &expression_variable_sp)
|
2010-08-04 01:40:35 +00:00
|
|
|
: StopInfo(plan_sp->GetThread(), LLDB_INVALID_UID), m_plan_sp(plan_sp),
|
2014-07-08 01:07:32 +00:00
|
|
|
m_return_valobj_sp(return_valobj_sp),
|
|
|
|
|
m_expression_variable_sp(expression_variable_sp) {}
|
2010-08-04 01:40:35 +00:00
|
|
|
|
2015-10-23 18:39:37 +00:00
|
|
|
~StopInfoThreadPlan() override = default;
|
|
|
|
|
|
2010-08-04 01:40:35 +00:00
|
|
|
StopReason GetStopReason() const override { return eStopReasonPlanComplete; }
|
|
|
|
|
|
2015-10-23 18:39:37 +00:00
|
|
|
const char *GetDescription() override {
|
2010-08-04 01:40:35 +00:00
|
|
|
if (m_description.empty()) {
|
|
|
|
|
StreamString strm;
|
|
|
|
|
m_plan_sp->GetDescription(&strm, eDescriptionLevelBrief);
|
2020-01-28 20:23:46 +01:00
|
|
|
m_description = std::string(strm.GetString());
|
2011-12-17 01:35:57 +00:00
|
|
|
}
|
2015-09-04 20:49:51 +00:00
|
|
|
return m_description.c_str();
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2015-09-04 20:49:51 +00:00
|
|
|
ValueObjectSP GetReturnValueObject() { return m_return_valobj_sp; }
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2014-07-08 01:07:32 +00:00
|
|
|
ExpressionVariableSP GetExpressionVariable() {
|
|
|
|
|
return m_expression_variable_sp;
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-02-09 01:29:05 +00:00
|
|
|
protected:
|
2015-10-23 18:39:37 +00:00
|
|
|
bool ShouldStop(Event *event_ptr) override {
|
2013-02-09 01:29:05 +00:00
|
|
|
if (m_plan_sp)
|
|
|
|
|
return m_plan_sp->ShouldStop(event_ptr);
|
|
|
|
|
else
|
|
|
|
|
return StopInfo::ShouldStop(event_ptr);
|
|
|
|
|
}
|
2010-08-04 01:40:35 +00:00
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
ThreadPlanSP m_plan_sp;
|
2011-12-17 01:35:57 +00:00
|
|
|
ValueObjectSP m_return_valobj_sp;
|
2015-09-04 20:49:51 +00:00
|
|
|
ExpressionVariableSP m_expression_variable_sp;
|
2010-08-04 01:40:35 +00:00
|
|
|
};
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2017-12-05 02:50:45 +00:00
|
|
|
// StopInfoExec
|
|
|
|
|
|
2012-12-05 00:16:59 +00:00
|
|
|
class StopInfoExec : public StopInfo {
|
|
|
|
|
public:
|
2022-03-14 13:32:03 -07:00
|
|
|
StopInfoExec(Thread &thread) : StopInfo(thread, LLDB_INVALID_UID) {}
|
2015-10-23 18:39:37 +00:00
|
|
|
|
|
|
|
|
~StopInfoExec() override = default;
|
|
|
|
|
|
2017-12-05 02:50:45 +00:00
|
|
|
bool ShouldStop(Event *event_ptr) override {
|
|
|
|
|
ThreadSP thread_sp(m_thread_wp.lock());
|
|
|
|
|
if (thread_sp)
|
|
|
|
|
return thread_sp->GetProcess()->GetStopOnExec();
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2015-10-23 18:39:37 +00:00
|
|
|
StopReason GetStopReason() const override { return eStopReasonExec; }
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-10-23 18:39:37 +00:00
|
|
|
const char *GetDescription() override { return "exec"; }
|
|
|
|
|
|
2012-12-05 00:16:59 +00:00
|
|
|
protected:
|
2015-10-23 18:39:37 +00:00
|
|
|
void PerformAction(Event *event_ptr) override {
|
2012-12-05 00:16:59 +00:00
|
|
|
// Only perform the action once
|
|
|
|
|
if (m_performed_action)
|
|
|
|
|
return;
|
|
|
|
|
m_performed_action = true;
|
2013-04-29 23:30:46 +00:00
|
|
|
ThreadSP thread_sp(m_thread_wp.lock());
|
|
|
|
|
if (thread_sp)
|
|
|
|
|
thread_sp->GetProcess()->DidExec();
|
2012-12-05 00:16:59 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2022-03-14 13:32:03 -07:00
|
|
|
bool m_performed_action = false;
|
2012-12-05 00:16:59 +00:00
|
|
|
};
|
|
|
|
|
|
2021-04-09 16:18:50 +02:00
|
|
|
// StopInfoFork
|
|
|
|
|
|
|
|
|
|
class StopInfoFork : public StopInfo {
|
|
|
|
|
public:
|
|
|
|
|
StopInfoFork(Thread &thread, lldb::pid_t child_pid, lldb::tid_t child_tid)
|
2022-03-14 13:32:03 -07:00
|
|
|
: StopInfo(thread, child_pid), m_child_pid(child_pid),
|
|
|
|
|
m_child_tid(child_tid) {}
|
2021-04-09 16:18:50 +02:00
|
|
|
|
|
|
|
|
~StopInfoFork() override = default;
|
|
|
|
|
|
|
|
|
|
bool ShouldStop(Event *event_ptr) override { return false; }
|
|
|
|
|
|
|
|
|
|
StopReason GetStopReason() const override { return eStopReasonFork; }
|
|
|
|
|
|
|
|
|
|
const char *GetDescription() override { return "fork"; }
|
|
|
|
|
|
|
|
|
|
protected:
|
|
|
|
|
void PerformAction(Event *event_ptr) override {
|
|
|
|
|
// Only perform the action once
|
|
|
|
|
if (m_performed_action)
|
|
|
|
|
return;
|
|
|
|
|
m_performed_action = true;
|
|
|
|
|
ThreadSP thread_sp(m_thread_wp.lock());
|
|
|
|
|
if (thread_sp)
|
|
|
|
|
thread_sp->GetProcess()->DidFork(m_child_pid, m_child_tid);
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-14 13:32:03 -07:00
|
|
|
bool m_performed_action = false;
|
2021-04-09 16:18:50 +02:00
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
lldb::pid_t m_child_pid;
|
|
|
|
|
lldb::tid_t m_child_tid;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
// StopInfoVFork
|
|
|
|
|
|
|
|
|
|
class StopInfoVFork : public StopInfo {
|
|
|
|
|
public:
|
|
|
|
|
StopInfoVFork(Thread &thread, lldb::pid_t child_pid, lldb::tid_t child_tid)
|
2022-03-14 13:32:03 -07:00
|
|
|
: StopInfo(thread, child_pid), m_child_pid(child_pid),
|
|
|
|
|
m_child_tid(child_tid) {}
|
2021-04-09 16:18:50 +02:00
|
|
|
|
|
|
|
|
~StopInfoVFork() override = default;
|
|
|
|
|
|
|
|
|
|
bool ShouldStop(Event *event_ptr) override { return false; }
|
|
|
|
|
|
|
|
|
|
StopReason GetStopReason() const override { return eStopReasonVFork; }
|
|
|
|
|
|
|
|
|
|
const char *GetDescription() override { return "vfork"; }
|
|
|
|
|
|
|
|
|
|
protected:
|
|
|
|
|
void PerformAction(Event *event_ptr) override {
|
|
|
|
|
// Only perform the action once
|
|
|
|
|
if (m_performed_action)
|
|
|
|
|
return;
|
|
|
|
|
m_performed_action = true;
|
|
|
|
|
ThreadSP thread_sp(m_thread_wp.lock());
|
|
|
|
|
if (thread_sp)
|
|
|
|
|
thread_sp->GetProcess()->DidVFork(m_child_pid, m_child_tid);
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-14 13:32:03 -07:00
|
|
|
bool m_performed_action = false;
|
2021-04-09 16:18:50 +02:00
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
lldb::pid_t m_child_pid;
|
|
|
|
|
lldb::tid_t m_child_tid;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
// StopInfoVForkDone
|
|
|
|
|
|
|
|
|
|
class StopInfoVForkDone : public StopInfo {
|
|
|
|
|
public:
|
2022-03-14 13:32:03 -07:00
|
|
|
StopInfoVForkDone(Thread &thread) : StopInfo(thread, 0) {}
|
2021-04-09 16:18:50 +02:00
|
|
|
|
|
|
|
|
~StopInfoVForkDone() override = default;
|
|
|
|
|
|
|
|
|
|
bool ShouldStop(Event *event_ptr) override { return false; }
|
|
|
|
|
|
|
|
|
|
StopReason GetStopReason() const override { return eStopReasonVForkDone; }
|
|
|
|
|
|
|
|
|
|
const char *GetDescription() override { return "vforkdone"; }
|
|
|
|
|
|
|
|
|
|
protected:
|
|
|
|
|
void PerformAction(Event *event_ptr) override {
|
|
|
|
|
// Only perform the action once
|
|
|
|
|
if (m_performed_action)
|
|
|
|
|
return;
|
|
|
|
|
m_performed_action = true;
|
|
|
|
|
ThreadSP thread_sp(m_thread_wp.lock());
|
|
|
|
|
if (thread_sp)
|
|
|
|
|
thread_sp->GetProcess()->DidVForkDone();
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-14 13:32:03 -07:00
|
|
|
bool m_performed_action = false;
|
2021-04-09 16:18:50 +02:00
|
|
|
};
|
|
|
|
|
|
2011-08-09 02:12:22 +00:00
|
|
|
} // namespace lldb_private
|
2010-08-04 01:40:35 +00:00
|
|
|
|
|
|
|
|
StopInfoSP StopInfo::CreateStopReasonWithBreakpointSiteID(Thread &thread,
|
|
|
|
|
break_id_t break_id) {
|
|
|
|
|
return StopInfoSP(new StopInfoBreakpoint(thread, break_id));
|
|
|
|
|
}
|
|
|
|
|
|
2010-10-14 23:45:03 +00:00
|
|
|
StopInfoSP StopInfo::CreateStopReasonWithBreakpointSiteID(Thread &thread,
|
|
|
|
|
break_id_t break_id,
|
|
|
|
|
bool should_stop) {
|
|
|
|
|
return StopInfoSP(new StopInfoBreakpoint(thread, break_id, should_stop));
|
|
|
|
|
}
|
|
|
|
|
|
[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
|
|
|
// LWP_TODO: We'll need a CreateStopReasonWithWatchpointResourceID akin
|
|
|
|
|
// to CreateStopReasonWithBreakpointSiteID
|
2023-04-12 17:53:51 -07:00
|
|
|
StopInfoSP StopInfo::CreateStopReasonWithWatchpointID(Thread &thread,
|
|
|
|
|
break_id_t watch_id,
|
|
|
|
|
bool silently_continue) {
|
|
|
|
|
return StopInfoSP(
|
|
|
|
|
new StopInfoWatchpoint(thread, watch_id, silently_continue));
|
2010-08-04 01:40:35 +00:00
|
|
|
}
|
|
|
|
|
|
Report inferior SIGSEGV as a signal instead of an exception on linux
Summary:
Previously, we reported inferior receiving SIGSEGV (or SIGILL, SIGFPE, SIGBUS) as an "exception"
to LLDB, presumably to match OSX behaviour. Beside the fact that we were basically lying to the
user, this was also causing problems with inferiors which handle SIGSEGV by themselves, since
LLDB was unable to reinject this signal back into the inferior.
This commit changes LLGS to report SIGSEGV as a signal. This has necessitated some changes in the
test-suite, which had previously used eStopReasonException to locate threads that crashed. Now it
uses platform-specific logic, which in the case of linux searches for eStopReasonSignaled with
signal=SIGSEGV.
I have also added the ability to set the description of StopInfoUnixSignal using the description
field of the gdb-remote packet. The linux stub uses this to display additional information about
the segfault (invalid address, address access protected, etc.).
Test Plan: All tests pass on linux and osx.
Reviewers: ovyalov, clayborg, emaste
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D10057
llvm-svn: 238549
2015-05-29 10:13:03 +00:00
|
|
|
StopInfoSP StopInfo::CreateStopReasonWithSignal(Thread &thread, int signo,
|
2023-03-14 11:52:48 +00:00
|
|
|
const char *description,
|
|
|
|
|
std::optional<int> code) {
|
2021-10-27 18:33:17 -07:00
|
|
|
thread.GetProcess()->GetUnixSignals()->IncrementSignalHitCount(signo);
|
2023-03-14 11:52:48 +00:00
|
|
|
return StopInfoSP(new StopInfoUnixSignal(thread, signo, description, code));
|
2010-08-04 01:40:35 +00:00
|
|
|
}
|
|
|
|
|
|
New ThreadPlanSingleThreadTimeout to resolve potential deadlock in single thread stepping (#90930)
This PR introduces a new `ThreadPlanSingleThreadTimeout` that will be
used to address potential deadlock during single-thread stepping.
While debugging a target with a non-trivial number of threads (around
5000 threads in one example target), we noticed that a simple step over
can take as long as 10 seconds. Enabling single-thread stepping mode
significantly reduces the stepping time to around 3 seconds. However,
this can introduce deadlock if we try to step over a method that depends
on other threads to release a lock.
To address this issue, we introduce a new
`ThreadPlanSingleThreadTimeout` that can be controlled by the
`target.process.thread.single-thread-plan-timeout` setting during
single-thread stepping mode. The concept involves counting the elapsed
time since the last internal stop to detect overall stepping progress.
Once a timeout occurs, we assume the target is not making progress due
to a potential deadlock, as mentioned above. We then send a new async
interrupt, resume all threads, and `ThreadPlanSingleThreadTimeout`
completes its task.
To support this design, the major changes made in this PR are:
1. `ThreadPlanSingleThreadTimeout` is popped during every internal stop
and reset (re-pushed) to the top of the stack (as a leaf node) during
resume. This is achieved by always returning `true` from
`ThreadPlanSingleThreadTimeout::DoPlanExplainsStop()` and
`ThreadPlanSingleThreadTimeout::MischiefManaged()`.
2. A new thread-specific async interrupt stop is introduced, which can
be detected/consumed by `ThreadPlanSingleThreadTimeout`.
3. The clearing of branch breakpoints in the range thread plan has been
moved from `DoPlanExplainsStop()` to `ShouldStop()`, as it is not
guaranteed that it will be called.
The detailed design is discussed in the RFC below:
[https://discourse.llvm.org/t/improve-single-thread-stepping/74599](https://discourse.llvm.org/t/improve-single-thread-stepping/74599)
---------
Co-authored-by: jeffreytan81 <jeffreytan@fb.com>
2024-08-05 17:26:39 -07:00
|
|
|
StopInfoSP StopInfo::CreateStopReasonWithInterrupt(Thread &thread, int signo,
|
|
|
|
|
const char *description) {
|
|
|
|
|
return StopInfoSP(new StopInfoInterrupt(thread, signo, description));
|
|
|
|
|
}
|
|
|
|
|
|
2010-08-04 01:40:35 +00:00
|
|
|
StopInfoSP StopInfo::CreateStopReasonToTrace(Thread &thread) {
|
|
|
|
|
return StopInfoSP(new StopInfoTrace(thread));
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-08 01:07:32 +00:00
|
|
|
StopInfoSP StopInfo::CreateStopReasonWithPlan(
|
|
|
|
|
ThreadPlanSP &plan_sp, ValueObjectSP return_valobj_sp,
|
2015-09-04 20:49:51 +00:00
|
|
|
ExpressionVariableSP expression_variable_sp) {
|
2014-07-08 01:07:32 +00:00
|
|
|
return StopInfoSP(new StopInfoThreadPlan(plan_sp, return_valobj_sp,
|
|
|
|
|
expression_variable_sp));
|
2010-08-04 01:40:35 +00:00
|
|
|
}
|
2011-06-04 01:26:29 +00:00
|
|
|
|
|
|
|
|
StopInfoSP StopInfo::CreateStopReasonWithException(Thread &thread,
|
|
|
|
|
const char *description) {
|
|
|
|
|
return StopInfoSP(new StopInfoException(thread, description));
|
|
|
|
|
}
|
2011-12-17 01:35:57 +00:00
|
|
|
|
2020-11-09 13:36:26 -08:00
|
|
|
StopInfoSP StopInfo::CreateStopReasonProcessorTrace(Thread &thread,
|
|
|
|
|
const char *description) {
|
|
|
|
|
return StopInfoSP(new StopInfoProcessorTrace(thread, description));
|
|
|
|
|
}
|
|
|
|
|
|
2012-12-05 00:16:59 +00:00
|
|
|
StopInfoSP StopInfo::CreateStopReasonWithExec(Thread &thread) {
|
|
|
|
|
return StopInfoSP(new StopInfoExec(thread));
|
|
|
|
|
}
|
|
|
|
|
|
2021-04-09 16:18:50 +02:00
|
|
|
StopInfoSP StopInfo::CreateStopReasonFork(Thread &thread,
|
|
|
|
|
lldb::pid_t child_pid,
|
|
|
|
|
lldb::tid_t child_tid) {
|
|
|
|
|
return StopInfoSP(new StopInfoFork(thread, child_pid, child_tid));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
StopInfoSP StopInfo::CreateStopReasonVFork(Thread &thread,
|
|
|
|
|
lldb::pid_t child_pid,
|
|
|
|
|
lldb::tid_t child_tid) {
|
|
|
|
|
return StopInfoSP(new StopInfoVFork(thread, child_pid, child_tid));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
StopInfoSP StopInfo::CreateStopReasonVForkDone(Thread &thread) {
|
|
|
|
|
return StopInfoSP(new StopInfoVForkDone(thread));
|
|
|
|
|
}
|
|
|
|
|
|
2011-12-17 01:35:57 +00:00
|
|
|
ValueObjectSP StopInfo::GetReturnValueObject(StopInfoSP &stop_info_sp) {
|
|
|
|
|
if (stop_info_sp &&
|
|
|
|
|
stop_info_sp->GetStopReason() == eStopReasonPlanComplete) {
|
|
|
|
|
StopInfoThreadPlan *plan_stop_info =
|
|
|
|
|
static_cast<StopInfoThreadPlan *>(stop_info_sp.get());
|
|
|
|
|
return plan_stop_info->GetReturnValueObject();
|
|
|
|
|
} else
|
|
|
|
|
return ValueObjectSP();
|
|
|
|
|
}
|
2014-07-08 01:07:32 +00:00
|
|
|
|
|
|
|
|
ExpressionVariableSP StopInfo::GetExpressionVariable(StopInfoSP &stop_info_sp) {
|
|
|
|
|
if (stop_info_sp &&
|
|
|
|
|
stop_info_sp->GetStopReason() == eStopReasonPlanComplete) {
|
|
|
|
|
StopInfoThreadPlan *plan_stop_info =
|
|
|
|
|
static_cast<StopInfoThreadPlan *>(stop_info_sp.get());
|
|
|
|
|
return plan_stop_info->GetExpressionVariable();
|
|
|
|
|
} else
|
2015-09-04 20:49:51 +00:00
|
|
|
return ExpressionVariableSP();
|
2014-07-08 01:07:32 +00:00
|
|
|
}
|
Added the "frame diagnose" command and use its output to make crash info better.
When a process stops due to a crash, we get the crashing instruction and the
crashing memory location (if there is one). From the user's perspective it is
often unclear what the reason for the crash is in a symbolic sense.
To address this, I have added new fuctionality to StackFrame to parse the
disassembly and reconstruct the sequence of dereferneces and offsets that were
applied to a known variable (or fuction retrn value) to obtain the invalid
pointer.
This makes use of enhancements in the disassembler, as well as new information
provided by the DWARF expression infrastructure, and is exposed through a
"frame diagnose" command. It is also used to provide symbolic information, when
available, in the event of a crash.
The algorithm is very rudimentary, and it needs a bunch of work, including
- better parsing for assembly, preferably with help from LLVM
- support for non-Apple platforms
- cleanup of the algorithm core, preferably to make it all work in terms of
Operands instead of register/offset pairs
- improvement of the GetExpressioPath() logic to make prettier expression
paths, and
- better handling of vtables.
I welcome all suggestios, improvements, and testcases.
llvm-svn: 280692
2016-09-06 04:48:36 +00:00
|
|
|
|
|
|
|
|
lldb::ValueObjectSP
|
|
|
|
|
StopInfo::GetCrashingDereference(StopInfoSP &stop_info_sp,
|
|
|
|
|
lldb::addr_t *crashing_address) {
|
|
|
|
|
if (!stop_info_sp) {
|
|
|
|
|
return ValueObjectSP();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const char *description = stop_info_sp->GetDescription();
|
|
|
|
|
if (!description) {
|
|
|
|
|
return ValueObjectSP();
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
Added the "frame diagnose" command and use its output to make crash info better.
When a process stops due to a crash, we get the crashing instruction and the
crashing memory location (if there is one). From the user's perspective it is
often unclear what the reason for the crash is in a symbolic sense.
To address this, I have added new fuctionality to StackFrame to parse the
disassembly and reconstruct the sequence of dereferneces and offsets that were
applied to a known variable (or fuction retrn value) to obtain the invalid
pointer.
This makes use of enhancements in the disassembler, as well as new information
provided by the DWARF expression infrastructure, and is exposed through a
"frame diagnose" command. It is also used to provide symbolic information, when
available, in the event of a crash.
The algorithm is very rudimentary, and it needs a bunch of work, including
- better parsing for assembly, preferably with help from LLVM
- support for non-Apple platforms
- cleanup of the algorithm core, preferably to make it all work in terms of
Operands instead of register/offset pairs
- improvement of the GetExpressioPath() logic to make prettier expression
paths, and
- better handling of vtables.
I welcome all suggestios, improvements, and testcases.
llvm-svn: 280692
2016-09-06 04:48:36 +00:00
|
|
|
ThreadSP thread_sp = stop_info_sp->GetThread();
|
|
|
|
|
if (!thread_sp) {
|
|
|
|
|
return ValueObjectSP();
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2023-04-21 13:49:01 -07:00
|
|
|
StackFrameSP frame_sp =
|
|
|
|
|
thread_sp->GetSelectedFrame(DoNoSelectMostRelevantFrame);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
Added the "frame diagnose" command and use its output to make crash info better.
When a process stops due to a crash, we get the crashing instruction and the
crashing memory location (if there is one). From the user's perspective it is
often unclear what the reason for the crash is in a symbolic sense.
To address this, I have added new fuctionality to StackFrame to parse the
disassembly and reconstruct the sequence of dereferneces and offsets that were
applied to a known variable (or fuction retrn value) to obtain the invalid
pointer.
This makes use of enhancements in the disassembler, as well as new information
provided by the DWARF expression infrastructure, and is exposed through a
"frame diagnose" command. It is also used to provide symbolic information, when
available, in the event of a crash.
The algorithm is very rudimentary, and it needs a bunch of work, including
- better parsing for assembly, preferably with help from LLVM
- support for non-Apple platforms
- cleanup of the algorithm core, preferably to make it all work in terms of
Operands instead of register/offset pairs
- improvement of the GetExpressioPath() logic to make prettier expression
paths, and
- better handling of vtables.
I welcome all suggestios, improvements, and testcases.
llvm-svn: 280692
2016-09-06 04:48:36 +00:00
|
|
|
if (!frame_sp) {
|
|
|
|
|
return ValueObjectSP();
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
Added the "frame diagnose" command and use its output to make crash info better.
When a process stops due to a crash, we get the crashing instruction and the
crashing memory location (if there is one). From the user's perspective it is
often unclear what the reason for the crash is in a symbolic sense.
To address this, I have added new fuctionality to StackFrame to parse the
disassembly and reconstruct the sequence of dereferneces and offsets that were
applied to a known variable (or fuction retrn value) to obtain the invalid
pointer.
This makes use of enhancements in the disassembler, as well as new information
provided by the DWARF expression infrastructure, and is exposed through a
"frame diagnose" command. It is also used to provide symbolic information, when
available, in the event of a crash.
The algorithm is very rudimentary, and it needs a bunch of work, including
- better parsing for assembly, preferably with help from LLVM
- support for non-Apple platforms
- cleanup of the algorithm core, preferably to make it all work in terms of
Operands instead of register/offset pairs
- improvement of the GetExpressioPath() logic to make prettier expression
paths, and
- better handling of vtables.
I welcome all suggestios, improvements, and testcases.
llvm-svn: 280692
2016-09-06 04:48:36 +00:00
|
|
|
const char address_string[] = "address=";
|
2016-09-06 20:57:50 +00:00
|
|
|
|
Added the "frame diagnose" command and use its output to make crash info better.
When a process stops due to a crash, we get the crashing instruction and the
crashing memory location (if there is one). From the user's perspective it is
often unclear what the reason for the crash is in a symbolic sense.
To address this, I have added new fuctionality to StackFrame to parse the
disassembly and reconstruct the sequence of dereferneces and offsets that were
applied to a known variable (or fuction retrn value) to obtain the invalid
pointer.
This makes use of enhancements in the disassembler, as well as new information
provided by the DWARF expression infrastructure, and is exposed through a
"frame diagnose" command. It is also used to provide symbolic information, when
available, in the event of a crash.
The algorithm is very rudimentary, and it needs a bunch of work, including
- better parsing for assembly, preferably with help from LLVM
- support for non-Apple platforms
- cleanup of the algorithm core, preferably to make it all work in terms of
Operands instead of register/offset pairs
- improvement of the GetExpressioPath() logic to make prettier expression
paths, and
- better handling of vtables.
I welcome all suggestios, improvements, and testcases.
llvm-svn: 280692
2016-09-06 04:48:36 +00:00
|
|
|
const char *address_loc = strstr(description, address_string);
|
|
|
|
|
if (!address_loc) {
|
|
|
|
|
return ValueObjectSP();
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
Added the "frame diagnose" command and use its output to make crash info better.
When a process stops due to a crash, we get the crashing instruction and the
crashing memory location (if there is one). From the user's perspective it is
often unclear what the reason for the crash is in a symbolic sense.
To address this, I have added new fuctionality to StackFrame to parse the
disassembly and reconstruct the sequence of dereferneces and offsets that were
applied to a known variable (or fuction retrn value) to obtain the invalid
pointer.
This makes use of enhancements in the disassembler, as well as new information
provided by the DWARF expression infrastructure, and is exposed through a
"frame diagnose" command. It is also used to provide symbolic information, when
available, in the event of a crash.
The algorithm is very rudimentary, and it needs a bunch of work, including
- better parsing for assembly, preferably with help from LLVM
- support for non-Apple platforms
- cleanup of the algorithm core, preferably to make it all work in terms of
Operands instead of register/offset pairs
- improvement of the GetExpressioPath() logic to make prettier expression
paths, and
- better handling of vtables.
I welcome all suggestios, improvements, and testcases.
llvm-svn: 280692
2016-09-06 04:48:36 +00:00
|
|
|
address_loc += (sizeof(address_string) - 1);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
[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
|
|
|
uint64_t address = strtoull(address_loc, nullptr, 0);
|
Added the "frame diagnose" command and use its output to make crash info better.
When a process stops due to a crash, we get the crashing instruction and the
crashing memory location (if there is one). From the user's perspective it is
often unclear what the reason for the crash is in a symbolic sense.
To address this, I have added new fuctionality to StackFrame to parse the
disassembly and reconstruct the sequence of dereferneces and offsets that were
applied to a known variable (or fuction retrn value) to obtain the invalid
pointer.
This makes use of enhancements in the disassembler, as well as new information
provided by the DWARF expression infrastructure, and is exposed through a
"frame diagnose" command. It is also used to provide symbolic information, when
available, in the event of a crash.
The algorithm is very rudimentary, and it needs a bunch of work, including
- better parsing for assembly, preferably with help from LLVM
- support for non-Apple platforms
- cleanup of the algorithm core, preferably to make it all work in terms of
Operands instead of register/offset pairs
- improvement of the GetExpressioPath() logic to make prettier expression
paths, and
- better handling of vtables.
I welcome all suggestios, improvements, and testcases.
llvm-svn: 280692
2016-09-06 04:48:36 +00:00
|
|
|
if (crashing_address) {
|
|
|
|
|
*crashing_address = address;
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
Added the "frame diagnose" command and use its output to make crash info better.
When a process stops due to a crash, we get the crashing instruction and the
crashing memory location (if there is one). From the user's perspective it is
often unclear what the reason for the crash is in a symbolic sense.
To address this, I have added new fuctionality to StackFrame to parse the
disassembly and reconstruct the sequence of dereferneces and offsets that were
applied to a known variable (or fuction retrn value) to obtain the invalid
pointer.
This makes use of enhancements in the disassembler, as well as new information
provided by the DWARF expression infrastructure, and is exposed through a
"frame diagnose" command. It is also used to provide symbolic information, when
available, in the event of a crash.
The algorithm is very rudimentary, and it needs a bunch of work, including
- better parsing for assembly, preferably with help from LLVM
- support for non-Apple platforms
- cleanup of the algorithm core, preferably to make it all work in terms of
Operands instead of register/offset pairs
- improvement of the GetExpressioPath() logic to make prettier expression
paths, and
- better handling of vtables.
I welcome all suggestios, improvements, and testcases.
llvm-svn: 280692
2016-09-06 04:48:36 +00:00
|
|
|
return frame_sp->GuessValueForAddress(address);
|
|
|
|
|
}
|