[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
|
|
|
//===-- ThreadPlanCallFunction.cpp ----------------------------------------===//
|
2010-06-08 16:52:24 +00:00
|
|
|
//
|
2019-01-19 08:50:56 +00:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2010-06-08 16:52:24 +00:00
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
2015-12-15 01:33:19 +00:00
|
|
|
#include "lldb/Target/ThreadPlanCallFunction.h"
|
2010-10-26 00:27:45 +00:00
|
|
|
#include "lldb/Breakpoint/Breakpoint.h"
|
|
|
|
|
#include "lldb/Breakpoint/BreakpointLocation.h"
|
2010-06-08 16:52:24 +00:00
|
|
|
#include "lldb/Core/Address.h"
|
2018-07-24 15:48:13 +00:00
|
|
|
#include "lldb/Core/DumpRegisterValue.h"
|
<rdar://problem/11757916>
Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file".
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()
Cleaned up header includes a bit as well.
llvm-svn: 162860
2012-08-29 21:13:06 +00:00
|
|
|
#include "lldb/Core/Module.h"
|
|
|
|
|
#include "lldb/Symbol/ObjectFile.h"
|
2015-03-03 19:23:09 +00:00
|
|
|
#include "lldb/Target/ABI.h"
|
2010-11-03 22:19:38 +00:00
|
|
|
#include "lldb/Target/LanguageRuntime.h"
|
2010-06-08 16:52:24 +00:00
|
|
|
#include "lldb/Target/Process.h"
|
|
|
|
|
#include "lldb/Target/RegisterContext.h"
|
2010-10-26 00:27:45 +00:00
|
|
|
#include "lldb/Target/StopInfo.h"
|
2010-06-08 16:52:24 +00:00
|
|
|
#include "lldb/Target/Target.h"
|
|
|
|
|
#include "lldb/Target/Thread.h"
|
|
|
|
|
#include "lldb/Target/ThreadPlanRunToAddress.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/Stream.h"
|
2010-06-08 16:52:24 +00:00
|
|
|
|
2019-02-11 23:13:08 +00:00
|
|
|
#include <memory>
|
|
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
using namespace lldb;
|
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
|
|
|
|
|
// ThreadPlanCallFunction: Plan to call a single function
|
2012-04-13 20:38:13 +00:00
|
|
|
bool ThreadPlanCallFunction::ConstructorSetup(
|
|
|
|
|
Thread &thread, ABI *&abi, lldb::addr_t &start_load_addr,
|
|
|
|
|
lldb::addr_t &function_load_addr) {
|
2021-11-02 08:58:19 -05:00
|
|
|
SetIsControllingPlan(true);
|
2012-05-11 18:43:38 +00:00
|
|
|
SetOkayToDiscard(false);
|
2012-12-07 17:56:31 +00:00
|
|
|
SetPrivate(true);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-02-21 00:09:25 +00:00
|
|
|
ProcessSP process_sp(thread.GetProcess());
|
|
|
|
|
if (!process_sp)
|
2012-04-13 20:38:13 +00:00
|
|
|
return false;
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2012-04-13 20:38:13 +00:00
|
|
|
abi = process_sp->GetABI().get();
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
if (!abi)
|
2012-04-13 20:38:13 +00:00
|
|
|
return false;
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Step);
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2010-11-03 01:37:52 +00:00
|
|
|
SetBreakpoints();
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2011-05-09 22:04:36 +00:00
|
|
|
m_function_sp = thread.GetRegisterContext()->GetSP() - abi->GetRedZoneSize();
|
2012-04-13 20:38:13 +00:00
|
|
|
// If we can't read memory at the point of the process where we are planning
|
2018-04-30 16:49:04 +00:00
|
|
|
// to put our function, we're not going to get any further...
|
2017-05-12 04:51:55 +00:00
|
|
|
Status error;
|
2012-04-13 20:38:13 +00:00
|
|
|
process_sp->ReadUnsignedIntegerFromMemory(m_function_sp, 4, 0, error);
|
|
|
|
|
if (!error.Success()) {
|
2013-03-28 00:04:05 +00:00
|
|
|
m_constructor_errors.Printf(
|
|
|
|
|
"Trying to put the stack in unreadable memory at: 0x%" PRIx64 ".",
|
|
|
|
|
m_function_sp);
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log, "ThreadPlanCallFunction(%p): %s.", static_cast<void *>(this),
|
|
|
|
|
m_constructor_errors.GetData());
|
2012-04-13 20:38:13 +00:00
|
|
|
return false;
|
|
|
|
|
}
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2019-07-19 00:52:08 +00:00
|
|
|
llvm::Expected<Address> start_address = GetTarget().GetEntryPointAddress();
|
|
|
|
|
if (!start_address) {
|
|
|
|
|
m_constructor_errors.Printf(
|
|
|
|
|
"%s", llvm::toString(start_address.takeError()).c_str());
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log, "ThreadPlanCallFunction(%p): %s.", static_cast<void *>(this),
|
|
|
|
|
m_constructor_errors.GetData());
|
2012-04-13 20:38:13 +00:00
|
|
|
return false;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2019-07-19 00:52:08 +00:00
|
|
|
m_start_addr = *start_address;
|
2013-11-07 00:11:47 +00:00
|
|
|
start_load_addr = m_start_addr.GetLoadAddress(&GetTarget());
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2011-01-20 02:03:18 +00:00
|
|
|
// Checkpoint the thread state so we can restore it later.
|
2011-01-22 01:27:23 +00:00
|
|
|
if (log && log->GetVerbose())
|
|
|
|
|
ReportRegisterState("About to checkpoint thread before function call. "
|
|
|
|
|
"Original register state was:");
|
|
|
|
|
|
2011-01-20 02:03:18 +00:00
|
|
|
if (!thread.CheckpointThreadState(m_stored_thread_state)) {
|
2013-03-28 00:04:05 +00:00
|
|
|
m_constructor_errors.Printf("Setting up ThreadPlanCallFunction, failed to "
|
|
|
|
|
"checkpoint thread state.");
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log, "ThreadPlanCallFunction(%p): %s.", static_cast<void *>(this),
|
|
|
|
|
m_constructor_errors.GetData());
|
2012-04-13 20:38:13 +00:00
|
|
|
return false;
|
2011-01-20 02:03:18 +00:00
|
|
|
}
|
2013-11-07 00:11:47 +00:00
|
|
|
function_load_addr = m_function_addr.GetLoadAddress(&GetTarget());
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2012-04-13 20:38:13 +00:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ThreadPlanCallFunction::ThreadPlanCallFunction(
|
2015-08-11 22:53:00 +00:00
|
|
|
Thread &thread, const Address &function, const CompilerType &return_type,
|
2013-11-08 01:14:26 +00:00
|
|
|
llvm::ArrayRef<addr_t> args, const EvaluateExpressionOptions &options)
|
2012-04-13 20:38:13 +00:00
|
|
|
: ThreadPlan(ThreadPlan::eKindCallFunction, "Call function plan", thread,
|
|
|
|
|
eVoteNoOpinion, eVoteNoOpinion),
|
2013-11-07 00:11:47 +00:00
|
|
|
m_valid(false), m_stop_other_threads(options.GetStopOthers()),
|
|
|
|
|
m_unwind_on_error(options.DoesUnwindOnError()),
|
|
|
|
|
m_ignore_breakpoints(options.DoesIgnoreBreakpoints()),
|
|
|
|
|
m_debug_execution(options.GetDebug()),
|
|
|
|
|
m_trap_exceptions(options.GetTrapExceptions()), m_function_addr(function),
|
[LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan. Part 2
Improve LLDB reliability by fixing the following "uninitialized variables" static code inspection warnings from
scan.coverity.com:
1476275, 1274012, 1455035, 1364789, 1454282
1467483, 1406152, 1406255, 1454837, 1454416
1467446, 1462022, 1461909, 1420566, 1327228
1367767, 1431254, 1467299, 1312678, 1431780
1454731, 1490403
Differential Revision: https://reviews.llvm.org/D130528
2022-07-25 15:52:21 -07:00
|
|
|
m_start_addr(), m_function_sp(0), m_subplan_sp(),
|
|
|
|
|
m_cxx_language_runtime(nullptr), m_objc_language_runtime(nullptr),
|
|
|
|
|
m_stored_thread_state(), m_real_stop_info_sp(), m_constructor_errors(),
|
|
|
|
|
m_return_valobj_sp(), m_takedown_done(false),
|
2013-11-07 00:11:47 +00:00
|
|
|
m_should_clear_objc_exception_bp(false),
|
|
|
|
|
m_should_clear_cxx_exception_bp(false),
|
Expression evaluation, a new ThreadPlanCallFunctionUsingABI for executing a function call on target via register manipulation
For Hexagon we want to be able to call functions during debugging, however currently lldb only supports this when there is JIT support.
Although emulation using IR interpretation is an alternative, it is currently limited in that it can't make function calls.
In this patch we have extended the IR interpreter so that it can execute a function call on the target using register manipulation.
To do this we need to handle the Call IR instruction, passing arguments to a new thread plan and collecting any return values to pass back into the IR interpreter.
The new thread plan is needed to call an alternative ABI interface of "ABI::PerpareTrivialCall()", allowing more detailed information about arguments and return values.
Reviewers: jingham, spyffe
Subscribers: emaste, lldb-commits, ted, ADodds, deepak2427
Differential Revision: http://reviews.llvm.org/D9404
llvm-svn: 242137
2015-07-14 10:56:58 +00:00
|
|
|
m_stop_address(LLDB_INVALID_ADDRESS), m_return_type(return_type) {
|
|
|
|
|
lldb::addr_t start_load_addr = LLDB_INVALID_ADDRESS;
|
|
|
|
|
lldb::addr_t function_load_addr = LLDB_INVALID_ADDRESS;
|
|
|
|
|
ABI *abi = nullptr;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-05-11 18:43:38 +00:00
|
|
|
if (!ConstructorSetup(thread, abi, start_load_addr, function_load_addr))
|
2012-04-13 20:38:13 +00:00
|
|
|
return;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-11-08 01:14:26 +00:00
|
|
|
if (!abi->PrepareTrivialCall(thread, m_function_sp, function_load_addr,
|
|
|
|
|
start_load_addr, args))
|
2012-02-21 00:09:25 +00:00
|
|
|
return;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-01-22 01:27:23 +00:00
|
|
|
ReportRegisterState("Function call was set up. Register state was:");
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-01-22 01:27:23 +00:00
|
|
|
m_valid = true;
|
|
|
|
|
}
|
|
|
|
|
|
Expression evaluation, a new ThreadPlanCallFunctionUsingABI for executing a function call on target via register manipulation
For Hexagon we want to be able to call functions during debugging, however currently lldb only supports this when there is JIT support.
Although emulation using IR interpretation is an alternative, it is currently limited in that it can't make function calls.
In this patch we have extended the IR interpreter so that it can execute a function call on the target using register manipulation.
To do this we need to handle the Call IR instruction, passing arguments to a new thread plan and collecting any return values to pass back into the IR interpreter.
The new thread plan is needed to call an alternative ABI interface of "ABI::PerpareTrivialCall()", allowing more detailed information about arguments and return values.
Reviewers: jingham, spyffe
Subscribers: emaste, lldb-commits, ted, ADodds, deepak2427
Differential Revision: http://reviews.llvm.org/D9404
llvm-svn: 242137
2015-07-14 10:56:58 +00:00
|
|
|
ThreadPlanCallFunction::ThreadPlanCallFunction(
|
|
|
|
|
Thread &thread, const Address &function,
|
|
|
|
|
const EvaluateExpressionOptions &options)
|
|
|
|
|
: ThreadPlan(ThreadPlan::eKindCallFunction, "Call function plan", thread,
|
|
|
|
|
eVoteNoOpinion, eVoteNoOpinion),
|
|
|
|
|
m_valid(false), m_stop_other_threads(options.GetStopOthers()),
|
|
|
|
|
m_unwind_on_error(options.DoesUnwindOnError()),
|
|
|
|
|
m_ignore_breakpoints(options.DoesIgnoreBreakpoints()),
|
|
|
|
|
m_debug_execution(options.GetDebug()),
|
|
|
|
|
m_trap_exceptions(options.GetTrapExceptions()), m_function_addr(function),
|
[LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan. Part 2
Improve LLDB reliability by fixing the following "uninitialized variables" static code inspection warnings from
scan.coverity.com:
1476275, 1274012, 1455035, 1364789, 1454282
1467483, 1406152, 1406255, 1454837, 1454416
1467446, 1462022, 1461909, 1420566, 1327228
1367767, 1431254, 1467299, 1312678, 1431780
1454731, 1490403
Differential Revision: https://reviews.llvm.org/D130528
2022-07-25 15:52:21 -07:00
|
|
|
m_start_addr(), m_function_sp(0), m_subplan_sp(),
|
|
|
|
|
m_cxx_language_runtime(nullptr), m_objc_language_runtime(nullptr),
|
|
|
|
|
m_stored_thread_state(), m_real_stop_info_sp(), m_constructor_errors(),
|
|
|
|
|
m_return_valobj_sp(), m_takedown_done(false),
|
2022-07-25 18:23:19 -07:00
|
|
|
m_should_clear_objc_exception_bp(false),
|
Expression evaluation, a new ThreadPlanCallFunctionUsingABI for executing a function call on target via register manipulation
For Hexagon we want to be able to call functions during debugging, however currently lldb only supports this when there is JIT support.
Although emulation using IR interpretation is an alternative, it is currently limited in that it can't make function calls.
In this patch we have extended the IR interpreter so that it can execute a function call on the target using register manipulation.
To do this we need to handle the Call IR instruction, passing arguments to a new thread plan and collecting any return values to pass back into the IR interpreter.
The new thread plan is needed to call an alternative ABI interface of "ABI::PerpareTrivialCall()", allowing more detailed information about arguments and return values.
Reviewers: jingham, spyffe
Subscribers: emaste, lldb-commits, ted, ADodds, deepak2427
Differential Revision: http://reviews.llvm.org/D9404
llvm-svn: 242137
2015-07-14 10:56:58 +00:00
|
|
|
m_should_clear_cxx_exception_bp(false),
|
|
|
|
|
m_stop_address(LLDB_INVALID_ADDRESS), m_return_type(CompilerType()) {}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-08-11 22:53:00 +00:00
|
|
|
ThreadPlanCallFunction::~ThreadPlanCallFunction() {
|
|
|
|
|
DoTakedown(PlanSucceeded());
|
Expression evaluation, a new ThreadPlanCallFunctionUsingABI for executing a function call on target via register manipulation
For Hexagon we want to be able to call functions during debugging, however currently lldb only supports this when there is JIT support.
Although emulation using IR interpretation is an alternative, it is currently limited in that it can't make function calls.
In this patch we have extended the IR interpreter so that it can execute a function call on the target using register manipulation.
To do this we need to handle the Call IR instruction, passing arguments to a new thread plan and collecting any return values to pass back into the IR interpreter.
The new thread plan is needed to call an alternative ABI interface of "ABI::PerpareTrivialCall()", allowing more detailed information about arguments and return values.
Reviewers: jingham, spyffe
Subscribers: emaste, lldb-commits, ted, ADodds, deepak2427
Differential Revision: http://reviews.llvm.org/D9404
llvm-svn: 242137
2015-07-14 10:56:58 +00:00
|
|
|
}
|
|
|
|
|
|
2011-01-22 01:27:23 +00:00
|
|
|
void ThreadPlanCallFunction::ReportRegisterState(const char *message) {
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Step);
|
2017-02-05 00:44:54 +00:00
|
|
|
if (log && log->GetVerbose()) {
|
2011-05-19 03:54:16 +00:00
|
|
|
StreamString strm;
|
2020-03-10 14:03:53 -07:00
|
|
|
RegisterContext *reg_ctx = GetThread().GetRegisterContext().get();
|
2011-01-22 01:27:23 +00:00
|
|
|
|
|
|
|
|
log->PutCString(message);
|
2010-11-04 01:51:38 +00:00
|
|
|
|
2013-03-27 23:08:40 +00:00
|
|
|
RegisterValue reg_value;
|
2014-04-04 04:06:10 +00:00
|
|
|
|
|
|
|
|
for (uint32_t reg_idx = 0, num_registers = reg_ctx->GetRegisterCount();
|
2011-05-19 03:54:16 +00:00
|
|
|
reg_idx < num_registers; ++reg_idx) {
|
2014-04-04 04:06:10 +00:00
|
|
|
const RegisterInfo *reg_info = reg_ctx->GetRegisterInfoAtIndex(reg_idx);
|
|
|
|
|
if (reg_ctx->ReadRegister(reg_info, reg_value)) {
|
2023-03-13 13:22:01 +00:00
|
|
|
DumpRegisterValue(reg_value, strm, *reg_info, true, false,
|
2018-07-24 15:48:13 +00:00
|
|
|
eFormatDefault);
|
2011-05-19 03:54:16 +00:00
|
|
|
strm.EOL();
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2012-04-13 23:11:52 +00:00
|
|
|
}
|
2016-11-16 21:15:24 +00:00
|
|
|
log->PutString(strm.GetString());
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
}
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2011-01-22 01:27:23 +00:00
|
|
|
void ThreadPlanCallFunction::DoTakedown(bool success) {
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Step);
|
[lldb] Restore register state if PrepareTrivialCall fails (#129038)
Fixes #124269
PrepareTrivalCall always had the possibility of failing, but given that
it only wrote to general purpose registers, if it did, you had bigger
problems.
When it failed, we did not mark the thread plan valid and when it was
torn down we didn't try to restore the register state. This meant that
if you tried to continue, the program was unlikely to work.
When I added AArch64 GCS support, I needed to handle the situation where
the GCS pointer points to unmapped memory and we fail to write the extra
entry we need. So I added code to restore the gcspr_el0 register
specifically if this happened, and ordered the operations so that we
tried this first.
In this change I've made the teardown of an invalid thread plan restore
the register state if one was saved. It may be there isn't one if
ConstructorSetup fails, but this is ok because that function does not
modify anything.
Now that we're doing that, I don't need the GCS specific code anymore,
and all thread plans are protected from this in the rare event something
does fail.
Testing is done by the existing GCS test case that points the gcspr into
unmapped memory which causes PrepareTrivialCall to fail. I tried adding
a simulated test using a mock gdb server. This was not possible because
they all use DynamicLoaderStatic which disables all JIT features.
2025-02-28 15:58:29 +00:00
|
|
|
Thread &thread = GetThread();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-01-22 01:27:23 +00:00
|
|
|
if (!m_valid) {
|
[lldb] Restore register state if PrepareTrivialCall fails (#129038)
Fixes #124269
PrepareTrivalCall always had the possibility of failing, but given that
it only wrote to general purpose registers, if it did, you had bigger
problems.
When it failed, we did not mark the thread plan valid and when it was
torn down we didn't try to restore the register state. This meant that
if you tried to continue, the program was unlikely to work.
When I added AArch64 GCS support, I needed to handle the situation where
the GCS pointer points to unmapped memory and we fail to write the extra
entry we need. So I added code to restore the gcspr_el0 register
specifically if this happened, and ordered the operations so that we
tried this first.
In this change I've made the teardown of an invalid thread plan restore
the register state if one was saved. It may be there isn't one if
ConstructorSetup fails, but this is ok because that function does not
modify anything.
Now that we're doing that, I don't need the GCS specific code anymore,
and all thread plans are protected from this in the rare event something
does fail.
Testing is done by the existing GCS test case that points the gcspr into
unmapped memory which causes PrepareTrivialCall to fail. I tried adding
a simulated test using a mock gdb server. This was not possible because
they all use DynamicLoaderStatic which disables all JIT features.
2025-02-28 15:58:29 +00:00
|
|
|
// If ConstructorSetup was succesfull but PrepareTrivialCall was not,
|
|
|
|
|
// we will have a saved register state and potentially modified registers.
|
|
|
|
|
// Restore those.
|
|
|
|
|
if (m_stored_thread_state.register_backup_sp)
|
|
|
|
|
if (!thread.RestoreRegisterStateFromCheckpoint(m_stored_thread_state))
|
|
|
|
|
LLDB_LOGF(
|
|
|
|
|
log,
|
|
|
|
|
"ThreadPlanCallFunction(%p): Failed to restore register state from "
|
|
|
|
|
"invalid plan that contained a saved register state.",
|
|
|
|
|
static_cast<void *>(this));
|
|
|
|
|
|
2014-04-04 04:06:10 +00:00
|
|
|
// Don't call DoTakedown if we were never valid to begin with.
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"ThreadPlanCallFunction(%p): Log called on "
|
|
|
|
|
"ThreadPlanCallFunction that was never valid.",
|
|
|
|
|
static_cast<void *>(this));
|
2016-09-06 20:57:50 +00:00
|
|
|
return;
|
2013-11-12 16:47:08 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-02-09 01:29:05 +00:00
|
|
|
if (!m_takedown_done) {
|
2012-05-10 01:35:39 +00:00
|
|
|
if (success) {
|
|
|
|
|
SetReturnValue();
|
2011-01-22 01:27:23 +00:00
|
|
|
}
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"ThreadPlanCallFunction(%p): DoTakedown called for thread "
|
|
|
|
|
"0x%4.4" PRIx64 ", m_valid: %d complete: %d.\n",
|
2020-03-10 14:03:53 -07:00
|
|
|
static_cast<void *>(this), m_tid, m_valid, IsPlanComplete());
|
2011-01-22 01:27:23 +00:00
|
|
|
m_takedown_done = true;
|
2011-11-01 02:46:54 +00:00
|
|
|
m_stop_address =
|
2020-03-10 14:03:53 -07:00
|
|
|
thread.GetStackFrameAtIndex(0)->GetRegisterContext()->GetPC();
|
2013-06-04 01:40:51 +00:00
|
|
|
m_real_stop_info_sp = GetPrivateStopInfo();
|
2020-03-10 14:03:53 -07:00
|
|
|
if (!thread.RestoreRegisterStateFromCheckpoint(m_stored_thread_state)) {
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"ThreadPlanCallFunction(%p): DoTakedown failed to restore "
|
|
|
|
|
"register state",
|
|
|
|
|
static_cast<void *>(this));
|
2011-01-20 02:03:18 +00:00
|
|
|
}
|
2013-01-15 02:47:48 +00:00
|
|
|
SetPlanComplete(success);
|
2011-01-20 02:03:18 +00:00
|
|
|
ClearBreakpoints();
|
2011-01-22 01:27:23 +00:00
|
|
|
if (log && log->GetVerbose())
|
|
|
|
|
ReportRegisterState("Restoring thread state after function call. "
|
|
|
|
|
"Restored register state:");
|
2016-09-06 20:57:50 +00:00
|
|
|
} else {
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"ThreadPlanCallFunction(%p): DoTakedown called as no-op for "
|
|
|
|
|
"thread 0x%4.4" PRIx64 ", m_valid: %d complete: %d.\n",
|
2020-03-10 14:03:53 -07:00
|
|
|
static_cast<void *>(this), m_tid, m_valid, IsPlanComplete());
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
2021-07-16 11:04:27 -07:00
|
|
|
void ThreadPlanCallFunction::DidPop() { DoTakedown(PlanSucceeded()); }
|
2011-01-18 01:58:06 +00:00
|
|
|
|
2011-05-14 01:50:35 +00:00
|
|
|
void ThreadPlanCallFunction::GetDescription(Stream *s, DescriptionLevel level) {
|
|
|
|
|
if (level == eDescriptionLevelBrief) {
|
2010-06-08 16:52:24 +00:00
|
|
|
s->Printf("Function call thread plan");
|
|
|
|
|
} else {
|
2012-11-29 21:49:15 +00:00
|
|
|
s->Printf("Thread plan to call 0x%" PRIx64,
|
2020-03-10 14:03:53 -07:00
|
|
|
m_function_addr.GetLoadAddress(&GetTarget()));
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool ThreadPlanCallFunction::ValidatePlan(Stream *error) {
|
|
|
|
|
if (!m_valid) {
|
2013-03-28 00:04:05 +00:00
|
|
|
if (error) {
|
|
|
|
|
if (m_constructor_errors.GetSize() > 0)
|
2016-11-16 21:15:24 +00:00
|
|
|
error->PutCString(m_constructor_errors.GetString());
|
2013-03-28 00:04:05 +00:00
|
|
|
else
|
|
|
|
|
error->PutCString("Unknown error");
|
|
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
return false;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2013-02-09 01:29:05 +00:00
|
|
|
Vote ThreadPlanCallFunction::ShouldReportStop(Event *event_ptr) {
|
|
|
|
|
if (m_takedown_done || IsPlanComplete())
|
|
|
|
|
return eVoteYes;
|
|
|
|
|
else
|
|
|
|
|
return ThreadPlan::ShouldReportStop(event_ptr);
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
bool ThreadPlanCallFunction::DoPlanExplainsStop(Event *event_ptr) {
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log(GetLog(LLDBLog::Step | LLDBLog::Process));
|
2013-06-04 01:40:51 +00:00
|
|
|
m_real_stop_info_sp = GetPrivateStopInfo();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// If our subplan knows why we stopped, even if it's done (which would
|
|
|
|
|
// forward the question to us) we answer yes.
|
2015-12-15 01:33:19 +00:00
|
|
|
if (m_subplan_sp && m_subplan_sp->PlanExplainsStop(event_ptr)) {
|
2013-01-15 02:47:48 +00:00
|
|
|
SetPlanComplete();
|
2010-10-26 00:27:45 +00:00
|
|
|
return true;
|
2013-01-15 02:47:48 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2010-11-03 19:36:28 +00:00
|
|
|
// Check if the breakpoint is one of ours.
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-05-10 01:35:39 +00:00
|
|
|
StopReason stop_reason;
|
|
|
|
|
if (!m_real_stop_info_sp)
|
|
|
|
|
stop_reason = eStopReasonNone;
|
|
|
|
|
else
|
|
|
|
|
stop_reason = m_real_stop_info_sp->GetStopReason();
|
2020-07-30 11:50:53 +02:00
|
|
|
LLDB_LOG(log,
|
|
|
|
|
"ThreadPlanCallFunction::PlanExplainsStop: Got stop reason - {0}.",
|
|
|
|
|
Thread::StopReasonAsString(stop_reason));
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-05-10 01:35:39 +00:00
|
|
|
if (stop_reason == eStopReasonBreakpoint && BreakpointsExplainStop())
|
2010-11-03 19:36:28 +00:00
|
|
|
return true;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2014-04-08 21:33:21 +00:00
|
|
|
// One more quirk here. If this event was from Halt interrupting the target,
|
2018-04-30 16:49:04 +00:00
|
|
|
// then we should not consider ourselves complete. Return true to
|
|
|
|
|
// acknowledge the stop.
|
2014-04-08 21:33:21 +00:00
|
|
|
if (Process::ProcessEventData::GetInterruptedFromEvent(event_ptr)) {
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log, "ThreadPlanCallFunction::PlanExplainsStop: The event is an "
|
|
|
|
|
"Interrupt, returning true.");
|
2012-05-10 01:35:39 +00:00
|
|
|
return true;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2012-05-10 01:35:39 +00:00
|
|
|
// We control breakpoints separately from other "stop reasons." So first,
|
2014-04-08 21:33:21 +00:00
|
|
|
// check the case where we stopped for an internal breakpoint, in that case,
|
2018-04-30 16:49:04 +00:00
|
|
|
// continue on. If it is not an internal breakpoint, consult
|
|
|
|
|
// m_ignore_breakpoints.
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2014-04-08 21:33:21 +00:00
|
|
|
if (stop_reason == eStopReasonBreakpoint) {
|
|
|
|
|
uint64_t break_site_id = m_real_stop_info_sp->GetValue();
|
|
|
|
|
BreakpointSiteSP bp_site_sp;
|
2020-03-10 14:03:53 -07:00
|
|
|
bp_site_sp = m_process.GetBreakpointSiteList().FindByID(break_site_id);
|
2010-10-26 00:27:45 +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
|
|
|
uint32_t num_owners = bp_site_sp->GetNumberOfConstituents();
|
2014-04-08 21:33:21 +00:00
|
|
|
bool is_internal = true;
|
2010-10-26 00:27:45 +00:00
|
|
|
for (uint32_t i = 0; i < num_owners; i++) {
|
[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 &bp = bp_site_sp->GetConstituentAtIndex(i)->GetBreakpoint();
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"ThreadPlanCallFunction::PlanExplainsStop: hit "
|
|
|
|
|
"breakpoint %d while calling function",
|
|
|
|
|
bp.GetID());
|
2013-02-09 01:29:05 +00:00
|
|
|
|
2013-01-15 02:47:48 +00:00
|
|
|
if (!bp.IsInternal()) {
|
2013-02-09 01:29:05 +00:00
|
|
|
is_internal = false;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (is_internal) {
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log, "ThreadPlanCallFunction::PlanExplainsStop hit an "
|
|
|
|
|
"internal breakpoint, not stopping.");
|
2013-02-09 01:29:05 +00:00
|
|
|
return false;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2010-10-26 00:27:45 +00:00
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
|
|
|
|
|
if (m_ignore_breakpoints) {
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log,
|
|
|
|
|
"ThreadPlanCallFunction::PlanExplainsStop: we are ignoring "
|
|
|
|
|
"breakpoints, overriding breakpoint stop info ShouldStop, "
|
|
|
|
|
"returning true");
|
2010-06-08 16:52:24 +00:00
|
|
|
m_real_stop_info_sp->OverrideShouldStop(false);
|
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
|
|
|
return true;
|
|
|
|
|
} else {
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log, "ThreadPlanCallFunction::PlanExplainsStop: we are not "
|
|
|
|
|
"ignoring breakpoints, overriding breakpoint stop info "
|
|
|
|
|
"ShouldStop, returning true");
|
2013-02-09 01:29:05 +00:00
|
|
|
m_real_stop_info_sp->OverrideShouldStop(true);
|
2010-06-08 16:52:24 +00:00
|
|
|
return false;
|
|
|
|
|
}
|
2013-02-09 01:29:05 +00:00
|
|
|
} else if (!m_unwind_on_error) {
|
|
|
|
|
// If we don't want to discard this plan, than any stop we don't understand
|
|
|
|
|
// should be propagated up the stack.
|
2010-10-26 00:27:45 +00:00
|
|
|
return false;
|
2016-09-06 20:57:50 +00:00
|
|
|
} else {
|
2018-04-30 16:49:04 +00:00
|
|
|
// If the subplan is running, any crashes are attributable to us. If we
|
|
|
|
|
// want to discard the plan, then we say we explain the stop but if we are
|
|
|
|
|
// going to be discarded, let whoever is above us explain the stop. But
|
|
|
|
|
// don't discard the plan if the stop would restart itself (for instance if
|
|
|
|
|
// it is a signal that is set not to stop. Check that here first. We just
|
|
|
|
|
// say we explain the stop but aren't done and everything will continue on
|
|
|
|
|
// from there.
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-05-07 18:51:04 +00:00
|
|
|
if (m_real_stop_info_sp &&
|
|
|
|
|
m_real_stop_info_sp->ShouldStopSynchronous(event_ptr)) {
|
2013-02-09 01:29:05 +00:00
|
|
|
SetPlanComplete(false);
|
2015-12-15 01:33:19 +00:00
|
|
|
return m_subplan_sp ? m_unwind_on_error : false;
|
2016-09-06 20:57:50 +00:00
|
|
|
} else
|
2012-05-11 18:43:38 +00:00
|
|
|
return true;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool ThreadPlanCallFunction::ShouldStop(Event *event_ptr) {
|
|
|
|
|
// We do some computation in DoPlanExplainsStop that may or may not set the
|
2018-04-30 16:49:04 +00:00
|
|
|
// plan as complete. We need to do that here to make sure our state is
|
|
|
|
|
// correct.
|
2010-06-08 16:52:24 +00:00
|
|
|
DoPlanExplainsStop(event_ptr);
|
|
|
|
|
|
2010-11-11 19:26:09 +00:00
|
|
|
if (IsPlanComplete()) {
|
|
|
|
|
ReportRegisterState("Function completed. Register state was:");
|
2010-06-08 16:52:24 +00:00
|
|
|
return true;
|
|
|
|
|
} else {
|
2012-05-11 18:43:38 +00:00
|
|
|
return false;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
2013-02-09 01:29:05 +00:00
|
|
|
bool ThreadPlanCallFunction::StopOthers() { return m_stop_other_threads; }
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-02-09 01:29:05 +00:00
|
|
|
StateType ThreadPlanCallFunction::GetPlanRunState() { return eStateRunning; }
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
void ThreadPlanCallFunction::DidPush() {
|
2010-10-26 00:31:56 +00:00
|
|
|
//#define SINGLE_STEP_EXPRESSIONS
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-11-26 23:52:18 +00:00
|
|
|
// Now set the thread state to "no reason" so we don't run with whatever
|
2018-04-30 16:49:04 +00:00
|
|
|
// signal was outstanding... Wait till the plan is pushed so we aren't
|
|
|
|
|
// changing the stop info till we're about to run.
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-11-26 23:52:18 +00:00
|
|
|
GetThread().SetStopInfoToNothing();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2010-10-26 00:31:56 +00:00
|
|
|
#ifndef SINGLE_STEP_EXPRESSIONS
|
2020-03-10 14:03:53 -07:00
|
|
|
Thread &thread = GetThread();
|
|
|
|
|
m_subplan_sp = std::make_shared<ThreadPlanRunToAddress>(thread, m_start_addr,
|
|
|
|
|
m_stop_other_threads);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2020-03-10 14:03:53 -07:00
|
|
|
thread.QueueThreadPlan(m_subplan_sp, false);
|
2011-01-20 02:03:18 +00:00
|
|
|
m_subplan_sp->SetPrivate(true);
|
2010-10-26 00:31:56 +00:00
|
|
|
#endif
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool ThreadPlanCallFunction::WillStop() { return true; }
|
|
|
|
|
|
|
|
|
|
bool ThreadPlanCallFunction::MischiefManaged() {
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Step);
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
if (IsPlanComplete()) {
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log, "ThreadPlanCallFunction(%p): Completed call function plan.",
|
|
|
|
|
static_cast<void *>(this));
|
2010-06-08 16:52:24 +00:00
|
|
|
|
|
|
|
|
ThreadPlan::MischiefManaged();
|
|
|
|
|
return true;
|
|
|
|
|
} else {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
2010-11-03 01:37:52 +00:00
|
|
|
|
|
|
|
|
void ThreadPlanCallFunction::SetBreakpoints() {
|
2020-03-10 14:03:53 -07:00
|
|
|
if (m_trap_exceptions) {
|
2012-02-21 00:09:25 +00:00
|
|
|
m_cxx_language_runtime =
|
2020-03-10 14:03:53 -07:00
|
|
|
m_process.GetLanguageRuntime(eLanguageTypeC_plus_plus);
|
|
|
|
|
m_objc_language_runtime = m_process.GetLanguageRuntime(eLanguageTypeObjC);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-02-21 00:09:25 +00:00
|
|
|
if (m_cxx_language_runtime) {
|
2013-11-07 00:11:47 +00:00
|
|
|
m_should_clear_cxx_exception_bp =
|
|
|
|
|
!m_cxx_language_runtime->ExceptionBreakpointsAreSet();
|
2012-02-21 00:09:25 +00:00
|
|
|
m_cxx_language_runtime->SetExceptionBreakpoints();
|
2013-11-07 00:11:47 +00:00
|
|
|
}
|
2012-02-21 00:09:25 +00:00
|
|
|
if (m_objc_language_runtime) {
|
2013-11-07 00:11:47 +00:00
|
|
|
m_should_clear_objc_exception_bp =
|
|
|
|
|
!m_objc_language_runtime->ExceptionBreakpointsAreSet();
|
2012-02-21 00:09:25 +00:00
|
|
|
m_objc_language_runtime->SetExceptionBreakpoints();
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2010-11-03 01:37:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ThreadPlanCallFunction::ClearBreakpoints() {
|
2013-11-07 00:11:47 +00:00
|
|
|
if (m_trap_exceptions) {
|
|
|
|
|
if (m_cxx_language_runtime && m_should_clear_cxx_exception_bp)
|
|
|
|
|
m_cxx_language_runtime->ClearExceptionBreakpoints();
|
|
|
|
|
if (m_objc_language_runtime && m_should_clear_objc_exception_bp)
|
|
|
|
|
m_objc_language_runtime->ClearExceptionBreakpoints();
|
|
|
|
|
}
|
2010-11-03 01:37:52 +00:00
|
|
|
}
|
2010-11-03 19:36:28 +00:00
|
|
|
|
|
|
|
|
bool ThreadPlanCallFunction::BreakpointsExplainStop() {
|
2013-06-04 01:40:51 +00:00
|
|
|
StopInfoSP stop_info_sp = GetPrivateStopInfo();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-11-07 00:11:47 +00:00
|
|
|
if (m_trap_exceptions) {
|
|
|
|
|
if ((m_cxx_language_runtime &&
|
|
|
|
|
m_cxx_language_runtime->ExceptionBreakpointsExplainStop(
|
|
|
|
|
stop_info_sp)) ||
|
|
|
|
|
(m_objc_language_runtime &&
|
|
|
|
|
m_objc_language_runtime->ExceptionBreakpointsExplainStop(
|
|
|
|
|
stop_info_sp))) {
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Step);
|
2019-07-24 17:56:10 +00:00
|
|
|
LLDB_LOGF(log, "ThreadPlanCallFunction::BreakpointsExplainStop - Hit an "
|
|
|
|
|
"exception breakpoint, setting plan complete.");
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-11-07 00:11:47 +00:00
|
|
|
SetPlanComplete(false);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// If the user has set the ObjC language breakpoint, it would normally
|
|
|
|
|
// get priority over our internal catcher breakpoint, but in this case we
|
|
|
|
|
// can't let that happen, so force the ShouldStop here.
|
2013-11-07 00:11:47 +00:00
|
|
|
stop_info_sp->OverrideShouldStop(true);
|
|
|
|
|
return true;
|
2013-01-15 02:47:48 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2010-11-03 19:36:28 +00:00
|
|
|
return false;
|
|
|
|
|
}
|
2012-11-26 23:52:18 +00:00
|
|
|
|
2014-03-07 11:16:37 +00:00
|
|
|
void ThreadPlanCallFunction::SetStopOthers(bool new_value) {
|
|
|
|
|
m_subplan_sp->SetStopOthers(new_value);
|
|
|
|
|
}
|
|
|
|
|
|
2021-02-14 22:49:16 -08:00
|
|
|
void ThreadPlanCallFunction::RestoreThreadState() {
|
|
|
|
|
GetThread().RestoreThreadStateFromCheckpoint(m_stored_thread_state);
|
2012-11-26 23:52:18 +00:00
|
|
|
}
|
|
|
|
|
|
Expression evaluation, a new ThreadPlanCallFunctionUsingABI for executing a function call on target via register manipulation
For Hexagon we want to be able to call functions during debugging, however currently lldb only supports this when there is JIT support.
Although emulation using IR interpretation is an alternative, it is currently limited in that it can't make function calls.
In this patch we have extended the IR interpreter so that it can execute a function call on the target using register manipulation.
To do this we need to handle the Call IR instruction, passing arguments to a new thread plan and collecting any return values to pass back into the IR interpreter.
The new thread plan is needed to call an alternative ABI interface of "ABI::PerpareTrivialCall()", allowing more detailed information about arguments and return values.
Reviewers: jingham, spyffe
Subscribers: emaste, lldb-commits, ted, ADodds, deepak2427
Differential Revision: http://reviews.llvm.org/D9404
llvm-svn: 242137
2015-07-14 10:56:58 +00:00
|
|
|
void ThreadPlanCallFunction::SetReturnValue() {
|
2020-03-10 14:03:53 -07:00
|
|
|
const ABI *abi = m_process.GetABI().get();
|
Expression evaluation, a new ThreadPlanCallFunctionUsingABI for executing a function call on target via register manipulation
For Hexagon we want to be able to call functions during debugging, however currently lldb only supports this when there is JIT support.
Although emulation using IR interpretation is an alternative, it is currently limited in that it can't make function calls.
In this patch we have extended the IR interpreter so that it can execute a function call on the target using register manipulation.
To do this we need to handle the Call IR instruction, passing arguments to a new thread plan and collecting any return values to pass back into the IR interpreter.
The new thread plan is needed to call an alternative ABI interface of "ABI::PerpareTrivialCall()", allowing more detailed information about arguments and return values.
Reviewers: jingham, spyffe
Subscribers: emaste, lldb-commits, ted, ADodds, deepak2427
Differential Revision: http://reviews.llvm.org/D9404
llvm-svn: 242137
2015-07-14 10:56:58 +00:00
|
|
|
if (abi && m_return_type.IsValid()) {
|
|
|
|
|
const bool persistent = false;
|
|
|
|
|
m_return_valobj_sp =
|
2020-03-10 14:03:53 -07:00
|
|
|
abi->GetReturnValueObject(GetThread(), m_return_type, persistent);
|
Expression evaluation, a new ThreadPlanCallFunctionUsingABI for executing a function call on target via register manipulation
For Hexagon we want to be able to call functions during debugging, however currently lldb only supports this when there is JIT support.
Although emulation using IR interpretation is an alternative, it is currently limited in that it can't make function calls.
In this patch we have extended the IR interpreter so that it can execute a function call on the target using register manipulation.
To do this we need to handle the Call IR instruction, passing arguments to a new thread plan and collecting any return values to pass back into the IR interpreter.
The new thread plan is needed to call an alternative ABI interface of "ABI::PerpareTrivialCall()", allowing more detailed information about arguments and return values.
Reviewers: jingham, spyffe
Subscribers: emaste, lldb-commits, ted, ADodds, deepak2427
Differential Revision: http://reviews.llvm.org/D9404
llvm-svn: 242137
2015-07-14 10:56:58 +00:00
|
|
|
}
|
|
|
|
|
}
|