2021-07-20 13:00:54 +00:00
|
|
|
//===-- ScriptedProcess.cpp -----------------------------------------------===//
|
|
|
|
|
//
|
|
|
|
|
// 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
|
|
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
|
|
#include "ScriptedProcess.h"
|
|
|
|
|
|
|
|
|
|
#include "lldb/Core/Debugger.h"
|
|
|
|
|
#include "lldb/Core/Module.h"
|
|
|
|
|
#include "lldb/Core/PluginManager.h"
|
|
|
|
|
|
|
|
|
|
#include "lldb/Host/OptionParser.h"
|
|
|
|
|
#include "lldb/Host/ThreadLauncher.h"
|
|
|
|
|
#include "lldb/Interpreter/CommandInterpreter.h"
|
|
|
|
|
#include "lldb/Interpreter/OptionArgParser.h"
|
|
|
|
|
#include "lldb/Interpreter/OptionGroupBoolean.h"
|
|
|
|
|
#include "lldb/Interpreter/ScriptInterpreter.h"
|
2022-12-05 13:54:21 -08:00
|
|
|
#include "lldb/Interpreter/ScriptedMetadata.h"
|
2021-07-20 13:00:54 +00:00
|
|
|
#include "lldb/Target/MemoryRegionInfo.h"
|
|
|
|
|
#include "lldb/Target/RegisterContext.h"
|
2022-02-03 13:26:10 +01:00
|
|
|
#include "lldb/Utility/LLDBLog.h"
|
2021-07-20 13:00:54 +00:00
|
|
|
#include "lldb/Utility/State.h"
|
|
|
|
|
|
|
|
|
|
#include <mutex>
|
|
|
|
|
|
|
|
|
|
LLDB_PLUGIN_DEFINE(ScriptedProcess)
|
|
|
|
|
|
|
|
|
|
using namespace lldb;
|
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
|
2021-10-22 19:53:43 +02:00
|
|
|
llvm::StringRef ScriptedProcess::GetPluginDescriptionStatic() {
|
2021-07-20 13:00:54 +00:00
|
|
|
return "Scripted Process plug-in.";
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static constexpr lldb::ScriptLanguage g_supported_script_languages[] = {
|
|
|
|
|
ScriptLanguage::eScriptLanguagePython,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
bool ScriptedProcess::IsScriptLanguageSupported(lldb::ScriptLanguage language) {
|
|
|
|
|
llvm::ArrayRef<lldb::ScriptLanguage> supported_languages =
|
2023-01-09 18:11:07 +01:00
|
|
|
llvm::ArrayRef(g_supported_script_languages);
|
2021-07-20 13:00:54 +00:00
|
|
|
|
|
|
|
|
return llvm::is_contained(supported_languages, language);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ScriptedProcess::CheckInterpreterAndScriptObject() const {
|
|
|
|
|
lldbassert(m_interpreter && "Invalid Script Interpreter.");
|
|
|
|
|
lldbassert(m_script_object_sp && "Invalid Script Object.");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
lldb::ProcessSP ScriptedProcess::CreateInstance(lldb::TargetSP target_sp,
|
|
|
|
|
lldb::ListenerSP listener_sp,
|
|
|
|
|
const FileSpec *file,
|
|
|
|
|
bool can_connect) {
|
|
|
|
|
if (!target_sp ||
|
|
|
|
|
!IsScriptLanguageSupported(target_sp->GetDebugger().GetScriptLanguage()))
|
|
|
|
|
return nullptr;
|
|
|
|
|
|
2022-12-05 13:54:21 -08:00
|
|
|
ScriptedMetadata scripted_metadata(target_sp->GetProcessLaunchInfo());
|
2021-07-20 13:00:54 +00:00
|
|
|
|
2022-12-05 13:54:21 -08:00
|
|
|
Status error;
|
|
|
|
|
auto process_sp = std::shared_ptr<ScriptedProcess>(
|
|
|
|
|
new ScriptedProcess(target_sp, listener_sp, scripted_metadata, error));
|
2021-07-20 13:00:54 +00:00
|
|
|
|
|
|
|
|
if (error.Fail() || !process_sp || !process_sp->m_script_object_sp ||
|
|
|
|
|
!process_sp->m_script_object_sp->IsValid()) {
|
2022-01-31 15:57:48 +01:00
|
|
|
LLDB_LOGF(GetLog(LLDBLog::Process), "%s", error.AsCString());
|
2021-07-20 13:00:54 +00:00
|
|
|
return nullptr;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return process_sp;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool ScriptedProcess::CanDebug(lldb::TargetSP target_sp,
|
|
|
|
|
bool plugin_specified_by_name) {
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2022-12-05 13:54:21 -08:00
|
|
|
ScriptedProcess::ScriptedProcess(lldb::TargetSP target_sp,
|
|
|
|
|
lldb::ListenerSP listener_sp,
|
|
|
|
|
const ScriptedMetadata &scripted_metadata,
|
|
|
|
|
Status &error)
|
|
|
|
|
: Process(target_sp, listener_sp), m_scripted_metadata(scripted_metadata) {
|
2021-07-20 13:00:54 +00:00
|
|
|
|
|
|
|
|
if (!target_sp) {
|
|
|
|
|
error.SetErrorStringWithFormat("ScriptedProcess::%s () - ERROR: %s",
|
|
|
|
|
__FUNCTION__, "Invalid target");
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
m_interpreter = target_sp->GetDebugger().GetScriptInterpreter();
|
|
|
|
|
|
|
|
|
|
if (!m_interpreter) {
|
|
|
|
|
error.SetErrorStringWithFormat("ScriptedProcess::%s () - ERROR: %s",
|
|
|
|
|
__FUNCTION__,
|
|
|
|
|
"Debugger has no Script Interpreter");
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2021-09-03 17:35:02 +00:00
|
|
|
ExecutionContext exe_ctx(target_sp, /*get_process=*/false);
|
|
|
|
|
|
|
|
|
|
StructuredData::GenericSP object_sp = GetInterface().CreatePluginObject(
|
2022-12-05 13:54:21 -08:00
|
|
|
m_scripted_metadata.GetClassName(), exe_ctx,
|
|
|
|
|
m_scripted_metadata.GetArgsSP());
|
2021-07-20 13:00:54 +00:00
|
|
|
|
|
|
|
|
if (!object_sp || !object_sp->IsValid()) {
|
|
|
|
|
error.SetErrorStringWithFormat("ScriptedProcess::%s () - ERROR: %s",
|
|
|
|
|
__FUNCTION__,
|
|
|
|
|
"Failed to create valid script object");
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
m_script_object_sp = object_sp;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ScriptedProcess::~ScriptedProcess() {
|
|
|
|
|
Clear();
|
|
|
|
|
// We need to call finalize on the process before destroying ourselves to
|
|
|
|
|
// make sure all of the broadcaster cleanup goes as planned. If we destruct
|
|
|
|
|
// this class, then Process::~Process() might have problems trying to fully
|
|
|
|
|
// destroy the broadcaster.
|
|
|
|
|
Finalize();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ScriptedProcess::Initialize() {
|
|
|
|
|
static llvm::once_flag g_once_flag;
|
|
|
|
|
|
|
|
|
|
llvm::call_once(g_once_flag, []() {
|
|
|
|
|
PluginManager::RegisterPlugin(GetPluginNameStatic(),
|
|
|
|
|
GetPluginDescriptionStatic(), CreateInstance);
|
|
|
|
|
});
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ScriptedProcess::Terminate() {
|
|
|
|
|
PluginManager::UnregisterPlugin(ScriptedProcess::CreateInstance);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Status ScriptedProcess::DoLoadCore() {
|
|
|
|
|
ProcessLaunchInfo launch_info = GetTarget().GetProcessLaunchInfo();
|
|
|
|
|
|
|
|
|
|
return DoLaunch(nullptr, launch_info);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Status ScriptedProcess::DoLaunch(Module *exe_module,
|
|
|
|
|
ProcessLaunchInfo &launch_info) {
|
|
|
|
|
CheckInterpreterAndScriptObject();
|
|
|
|
|
|
|
|
|
|
/* FIXME: This doesn't reflect how lldb actually launches a process.
|
|
|
|
|
In reality, it attaches to debugserver, then resume the process. */
|
|
|
|
|
Status error = GetInterface().Launch();
|
|
|
|
|
SetPrivateState(eStateRunning);
|
|
|
|
|
|
|
|
|
|
if (error.Fail())
|
|
|
|
|
return error;
|
|
|
|
|
|
|
|
|
|
// TODO: Fetch next state from stopped event queue then send stop event
|
|
|
|
|
// const StateType state = SetThreadStopInfo(response);
|
|
|
|
|
// if (state != eStateInvalid) {
|
|
|
|
|
// SetPrivateState(state);
|
|
|
|
|
|
|
|
|
|
SetPrivateState(eStateStopped);
|
|
|
|
|
|
|
|
|
|
return {};
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ScriptedProcess::DidLaunch() {
|
|
|
|
|
CheckInterpreterAndScriptObject();
|
|
|
|
|
m_pid = GetInterface().GetProcessID();
|
2022-03-04 11:22:32 -08:00
|
|
|
GetLoadedDynamicLibrariesInfos();
|
2021-07-20 13:00:54 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Status ScriptedProcess::DoResume() {
|
|
|
|
|
CheckInterpreterAndScriptObject();
|
|
|
|
|
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Process);
|
2021-07-20 13:00:54 +00:00
|
|
|
// FIXME: Fetch data from thread.
|
|
|
|
|
const StateType thread_resume_state = eStateRunning;
|
|
|
|
|
LLDB_LOGF(log, "ScriptedProcess::%s thread_resume_state = %s", __FUNCTION__,
|
|
|
|
|
StateAsCString(thread_resume_state));
|
|
|
|
|
|
|
|
|
|
bool resume = (thread_resume_state == eStateRunning);
|
|
|
|
|
assert(thread_resume_state == eStateRunning && "invalid thread resume state");
|
|
|
|
|
|
|
|
|
|
Status error;
|
|
|
|
|
if (resume) {
|
|
|
|
|
LLDB_LOGF(log, "ScriptedProcess::%s sending resume", __FUNCTION__);
|
|
|
|
|
|
|
|
|
|
SetPrivateState(eStateRunning);
|
|
|
|
|
SetPrivateState(eStateStopped);
|
|
|
|
|
error = GetInterface().Resume();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return error;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Status ScriptedProcess::DoStop() {
|
|
|
|
|
CheckInterpreterAndScriptObject();
|
|
|
|
|
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Process);
|
2021-07-20 13:00:54 +00:00
|
|
|
|
|
|
|
|
if (GetInterface().ShouldStop()) {
|
|
|
|
|
SetPrivateState(eStateStopped);
|
|
|
|
|
LLDB_LOGF(log, "ScriptedProcess::%s Immediate stop", __FUNCTION__);
|
|
|
|
|
return {};
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
LLDB_LOGF(log, "ScriptedProcess::%s Delayed stop", __FUNCTION__);
|
|
|
|
|
return GetInterface().Stop();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Status ScriptedProcess::DoDestroy() { return Status(); }
|
|
|
|
|
|
|
|
|
|
bool ScriptedProcess::IsAlive() {
|
|
|
|
|
if (m_interpreter && m_script_object_sp)
|
|
|
|
|
return GetInterface().IsAlive();
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
size_t ScriptedProcess::DoReadMemory(lldb::addr_t addr, void *buf, size_t size,
|
|
|
|
|
Status &error) {
|
|
|
|
|
if (!m_interpreter)
|
2022-01-18 12:56:42 +01:00
|
|
|
return ScriptedInterface::ErrorWithMessage<size_t>(
|
|
|
|
|
LLVM_PRETTY_FUNCTION, "No interpreter.", error);
|
2021-07-20 13:00:54 +00:00
|
|
|
|
|
|
|
|
lldb::DataExtractorSP data_extractor_sp =
|
|
|
|
|
GetInterface().ReadMemoryAtAddress(addr, size, error);
|
|
|
|
|
|
[lldb/Plugins] Add memory region support in ScriptedProcess
This patch adds support for memory regions in Scripted Processes.
This is necessary to read the stack memory region in order to
reconstruct each stackframe of the program.
In order to do so, this patch makes some changes to the SBAPI, namely:
- Add a new constructor for `SBMemoryRegionInfo` that takes arguments
such as the memory region name, address range, permissions ...
This is used when reading memory at some address to compute the offset
in the binary blob provided by the user.
- Add a `GetMemoryRegionContainingAddress` method to `SBMemoryRegionInfoList`
to simplify the access to a specific memory region.
With these changes, lldb is now able to unwind the stack and reconstruct
each frame. On top of that, reloading the target module at offset 0 allows
lldb to symbolicate the `ScriptedProcess` using debug info, similarly to an
ordinary Process.
To test this, I wrote a simple program with multiple function calls, ran it in
lldb, stopped at a leaf function and read the registers values and copied
the stack memory into a binary file. These are then used in the python script.
Differential Revision: https://reviews.llvm.org/D108953
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2021-10-08 12:25:04 +00:00
|
|
|
if (!data_extractor_sp || !data_extractor_sp->GetByteSize() || error.Fail())
|
2021-07-20 13:00:54 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
offset_t bytes_copied = data_extractor_sp->CopyByteOrderedData(
|
|
|
|
|
0, data_extractor_sp->GetByteSize(), buf, size, GetByteOrder());
|
|
|
|
|
|
|
|
|
|
if (!bytes_copied || bytes_copied == LLDB_INVALID_OFFSET)
|
2022-01-18 12:56:42 +01:00
|
|
|
return ScriptedInterface::ErrorWithMessage<size_t>(
|
2021-10-08 18:48:02 +00:00
|
|
|
LLVM_PRETTY_FUNCTION, "Failed to copy read memory to buffer.", error);
|
2021-07-20 13:00:54 +00:00
|
|
|
|
|
|
|
|
return size;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ArchSpec ScriptedProcess::GetArchitecture() {
|
|
|
|
|
return GetTarget().GetArchitecture();
|
|
|
|
|
}
|
|
|
|
|
|
2021-12-01 16:14:54 +00:00
|
|
|
Status ScriptedProcess::DoGetMemoryRegionInfo(lldb::addr_t load_addr,
|
|
|
|
|
MemoryRegionInfo ®ion) {
|
[lldb/Plugins] Add memory region support in ScriptedProcess
This patch adds support for memory regions in Scripted Processes.
This is necessary to read the stack memory region in order to
reconstruct each stackframe of the program.
In order to do so, this patch makes some changes to the SBAPI, namely:
- Add a new constructor for `SBMemoryRegionInfo` that takes arguments
such as the memory region name, address range, permissions ...
This is used when reading memory at some address to compute the offset
in the binary blob provided by the user.
- Add a `GetMemoryRegionContainingAddress` method to `SBMemoryRegionInfoList`
to simplify the access to a specific memory region.
With these changes, lldb is now able to unwind the stack and reconstruct
each frame. On top of that, reloading the target module at offset 0 allows
lldb to symbolicate the `ScriptedProcess` using debug info, similarly to an
ordinary Process.
To test this, I wrote a simple program with multiple function calls, ran it in
lldb, stopped at a leaf function and read the registers values and copied
the stack memory into a binary file. These are then used in the python script.
Differential Revision: https://reviews.llvm.org/D108953
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2021-10-08 12:25:04 +00:00
|
|
|
CheckInterpreterAndScriptObject();
|
|
|
|
|
|
|
|
|
|
Status error;
|
|
|
|
|
if (auto region_or_err =
|
|
|
|
|
GetInterface().GetMemoryRegionContainingAddress(load_addr, error))
|
|
|
|
|
region = *region_or_err;
|
|
|
|
|
|
|
|
|
|
return error;
|
2021-07-20 13:00:54 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Status ScriptedProcess::GetMemoryRegions(MemoryRegionInfos ®ion_list) {
|
|
|
|
|
CheckInterpreterAndScriptObject();
|
|
|
|
|
|
[lldb/Plugins] Add memory region support in ScriptedProcess
This patch adds support for memory regions in Scripted Processes.
This is necessary to read the stack memory region in order to
reconstruct each stackframe of the program.
In order to do so, this patch makes some changes to the SBAPI, namely:
- Add a new constructor for `SBMemoryRegionInfo` that takes arguments
such as the memory region name, address range, permissions ...
This is used when reading memory at some address to compute the offset
in the binary blob provided by the user.
- Add a `GetMemoryRegionContainingAddress` method to `SBMemoryRegionInfoList`
to simplify the access to a specific memory region.
With these changes, lldb is now able to unwind the stack and reconstruct
each frame. On top of that, reloading the target module at offset 0 allows
lldb to symbolicate the `ScriptedProcess` using debug info, similarly to an
ordinary Process.
To test this, I wrote a simple program with multiple function calls, ran it in
lldb, stopped at a leaf function and read the registers values and copied
the stack memory into a binary file. These are then used in the python script.
Differential Revision: https://reviews.llvm.org/D108953
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2021-10-08 12:25:04 +00:00
|
|
|
Status error;
|
2021-07-20 13:00:54 +00:00
|
|
|
lldb::addr_t address = 0;
|
|
|
|
|
|
[lldb/Plugins] Add memory region support in ScriptedProcess
This patch adds support for memory regions in Scripted Processes.
This is necessary to read the stack memory region in order to
reconstruct each stackframe of the program.
In order to do so, this patch makes some changes to the SBAPI, namely:
- Add a new constructor for `SBMemoryRegionInfo` that takes arguments
such as the memory region name, address range, permissions ...
This is used when reading memory at some address to compute the offset
in the binary blob provided by the user.
- Add a `GetMemoryRegionContainingAddress` method to `SBMemoryRegionInfoList`
to simplify the access to a specific memory region.
With these changes, lldb is now able to unwind the stack and reconstruct
each frame. On top of that, reloading the target module at offset 0 allows
lldb to symbolicate the `ScriptedProcess` using debug info, similarly to an
ordinary Process.
To test this, I wrote a simple program with multiple function calls, ran it in
lldb, stopped at a leaf function and read the registers values and copied
the stack memory into a binary file. These are then used in the python script.
Differential Revision: https://reviews.llvm.org/D108953
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2021-10-08 12:25:04 +00:00
|
|
|
while (auto region_or_err =
|
|
|
|
|
GetInterface().GetMemoryRegionContainingAddress(address, error)) {
|
|
|
|
|
if (error.Fail())
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
MemoryRegionInfo &mem_region = *region_or_err;
|
|
|
|
|
auto range = mem_region.GetRange();
|
2021-07-20 13:00:54 +00:00
|
|
|
address += range.GetRangeBase() + range.GetByteSize();
|
[lldb/Plugins] Add memory region support in ScriptedProcess
This patch adds support for memory regions in Scripted Processes.
This is necessary to read the stack memory region in order to
reconstruct each stackframe of the program.
In order to do so, this patch makes some changes to the SBAPI, namely:
- Add a new constructor for `SBMemoryRegionInfo` that takes arguments
such as the memory region name, address range, permissions ...
This is used when reading memory at some address to compute the offset
in the binary blob provided by the user.
- Add a `GetMemoryRegionContainingAddress` method to `SBMemoryRegionInfoList`
to simplify the access to a specific memory region.
With these changes, lldb is now able to unwind the stack and reconstruct
each frame. On top of that, reloading the target module at offset 0 allows
lldb to symbolicate the `ScriptedProcess` using debug info, similarly to an
ordinary Process.
To test this, I wrote a simple program with multiple function calls, ran it in
lldb, stopped at a leaf function and read the registers values and copied
the stack memory into a binary file. These are then used in the python script.
Differential Revision: https://reviews.llvm.org/D108953
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2021-10-08 12:25:04 +00:00
|
|
|
region_list.push_back(mem_region);
|
2021-07-20 13:00:54 +00:00
|
|
|
}
|
|
|
|
|
|
[lldb/Plugins] Add memory region support in ScriptedProcess
This patch adds support for memory regions in Scripted Processes.
This is necessary to read the stack memory region in order to
reconstruct each stackframe of the program.
In order to do so, this patch makes some changes to the SBAPI, namely:
- Add a new constructor for `SBMemoryRegionInfo` that takes arguments
such as the memory region name, address range, permissions ...
This is used when reading memory at some address to compute the offset
in the binary blob provided by the user.
- Add a `GetMemoryRegionContainingAddress` method to `SBMemoryRegionInfoList`
to simplify the access to a specific memory region.
With these changes, lldb is now able to unwind the stack and reconstruct
each frame. On top of that, reloading the target module at offset 0 allows
lldb to symbolicate the `ScriptedProcess` using debug info, similarly to an
ordinary Process.
To test this, I wrote a simple program with multiple function calls, ran it in
lldb, stopped at a leaf function and read the registers values and copied
the stack memory into a binary file. These are then used in the python script.
Differential Revision: https://reviews.llvm.org/D108953
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2021-10-08 12:25:04 +00:00
|
|
|
return error;
|
2021-07-20 13:00:54 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ScriptedProcess::Clear() { Process::m_thread_list.Clear(); }
|
|
|
|
|
|
|
|
|
|
bool ScriptedProcess::DoUpdateThreadList(ThreadList &old_thread_list,
|
|
|
|
|
ThreadList &new_thread_list) {
|
|
|
|
|
// TODO: Implement
|
|
|
|
|
// This is supposed to get the current set of threads, if any of them are in
|
|
|
|
|
// old_thread_list then they get copied to new_thread_list, and then any
|
|
|
|
|
// actually new threads will get added to new_thread_list.
|
2021-10-06 00:09:20 +00:00
|
|
|
|
|
|
|
|
CheckInterpreterAndScriptObject();
|
2021-11-10 19:53:14 +00:00
|
|
|
m_thread_plans.ClearThreadCache();
|
2021-10-06 00:09:20 +00:00
|
|
|
|
|
|
|
|
Status error;
|
|
|
|
|
ScriptLanguage language = m_interpreter->GetLanguage();
|
|
|
|
|
|
|
|
|
|
if (language != eScriptLanguagePython)
|
2022-01-18 12:56:42 +01:00
|
|
|
return ScriptedInterface::ErrorWithMessage<bool>(
|
2021-10-08 18:48:02 +00:00
|
|
|
LLVM_PRETTY_FUNCTION,
|
2021-10-06 00:09:20 +00:00
|
|
|
llvm::Twine("ScriptInterpreter language (" +
|
|
|
|
|
llvm::Twine(m_interpreter->LanguageToString(language)) +
|
|
|
|
|
llvm::Twine(") not supported."))
|
|
|
|
|
.str(),
|
|
|
|
|
error);
|
|
|
|
|
|
2022-01-18 12:45:57 +01:00
|
|
|
StructuredData::DictionarySP thread_info_sp = GetInterface().GetThreadsInfo();
|
2021-10-06 00:09:20 +00:00
|
|
|
|
2022-01-18 12:45:57 +01:00
|
|
|
if (!thread_info_sp)
|
2022-01-18 12:56:42 +01:00
|
|
|
return ScriptedInterface::ErrorWithMessage<bool>(
|
2022-01-18 12:45:57 +01:00
|
|
|
LLVM_PRETTY_FUNCTION,
|
|
|
|
|
"Couldn't fetch thread list from Scripted Process.", error);
|
|
|
|
|
|
[lldb/Plugin] Sort the ScriptedProcess' thread list before creating threads
With Scripted Processes, in order to create scripted threads, the blueprint
provides a dictionary that have each thread index as the key with the respective
thread instance as the pair value.
In Python, this is fine because a dictionary key can be of any type including
integer types:
```
>>> {1: "one", 2: "two", 10: "ten"}
{1: 'one', 2: 'two', 10: 'ten'}
```
However, when the python dictionary gets bridged to C++ we convert it to a
`StructuredData::Dictionary` that uses a `std::map<ConstString, ObjectSP>`
for storage.
Because `std::map` is an ordered container and ours uses the `ConstString`
type for keys, the thread indices gets converted to strings which makes the
dictionary sorted alphabetically, instead of numerically.
If the ScriptedProcess has 10 threads or more, it causes thread “10”
(and higher) to be after thread “1”, but before thread “2”.
In order to solve this, this sorts the thread info dictionary keys
numerically, before iterating over them to create ScriptedThreads.
rdar://90327854
Differential Revision: https://reviews.llvm.org/D122429
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2022-03-25 14:25:23 -07:00
|
|
|
// Because `StructuredData::Dictionary` uses a `std::map<ConstString,
|
|
|
|
|
// ObjectSP>` for storage, each item is sorted based on the key alphabetical
|
|
|
|
|
// order. Since `GetThreadsInfo` provides thread indices as the key element,
|
|
|
|
|
// thread info comes ordered alphabetically, instead of numerically, so we
|
|
|
|
|
// need to sort the thread indices before creating thread.
|
|
|
|
|
|
|
|
|
|
StructuredData::ArraySP keys = thread_info_sp->GetKeys();
|
|
|
|
|
|
|
|
|
|
std::map<size_t, StructuredData::ObjectSP> sorted_threads;
|
|
|
|
|
auto sort_keys = [&sorted_threads,
|
|
|
|
|
&thread_info_sp](StructuredData::Object *item) -> bool {
|
|
|
|
|
if (!item)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
llvm::StringRef key = item->GetStringValue();
|
|
|
|
|
size_t idx = 0;
|
|
|
|
|
|
|
|
|
|
// Make sure the provided index is actually an integer
|
|
|
|
|
if (!llvm::to_integer(key, idx))
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
sorted_threads[idx] = thread_info_sp->GetValueForKey(key);
|
|
|
|
|
return true;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
size_t thread_count = thread_info_sp->GetSize();
|
|
|
|
|
|
|
|
|
|
if (!keys->ForEach(sort_keys) || sorted_threads.size() != thread_count)
|
|
|
|
|
// Might be worth showing the unsorted thread list instead of return early.
|
|
|
|
|
return ScriptedInterface::ErrorWithMessage<bool>(
|
|
|
|
|
LLVM_PRETTY_FUNCTION, "Couldn't sort thread list.", error);
|
|
|
|
|
|
2022-01-18 12:45:57 +01:00
|
|
|
auto create_scripted_thread =
|
[lldb/Plugin] Sort the ScriptedProcess' thread list before creating threads
With Scripted Processes, in order to create scripted threads, the blueprint
provides a dictionary that have each thread index as the key with the respective
thread instance as the pair value.
In Python, this is fine because a dictionary key can be of any type including
integer types:
```
>>> {1: "one", 2: "two", 10: "ten"}
{1: 'one', 2: 'two', 10: 'ten'}
```
However, when the python dictionary gets bridged to C++ we convert it to a
`StructuredData::Dictionary` that uses a `std::map<ConstString, ObjectSP>`
for storage.
Because `std::map` is an ordered container and ours uses the `ConstString`
type for keys, the thread indices gets converted to strings which makes the
dictionary sorted alphabetically, instead of numerically.
If the ScriptedProcess has 10 threads or more, it causes thread “10”
(and higher) to be after thread “1”, but before thread “2”.
In order to solve this, this sorts the thread info dictionary keys
numerically, before iterating over them to create ScriptedThreads.
rdar://90327854
Differential Revision: https://reviews.llvm.org/D122429
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2022-03-25 14:25:23 -07:00
|
|
|
[this, &error, &new_thread_list](
|
|
|
|
|
const std::pair<size_t, StructuredData::ObjectSP> pair) -> bool {
|
|
|
|
|
size_t idx = pair.first;
|
|
|
|
|
StructuredData::ObjectSP object_sp = pair.second;
|
2022-01-18 12:45:57 +01:00
|
|
|
|
[lldb/Plugin] Sort the ScriptedProcess' thread list before creating threads
With Scripted Processes, in order to create scripted threads, the blueprint
provides a dictionary that have each thread index as the key with the respective
thread instance as the pair value.
In Python, this is fine because a dictionary key can be of any type including
integer types:
```
>>> {1: "one", 2: "two", 10: "ten"}
{1: 'one', 2: 'two', 10: 'ten'}
```
However, when the python dictionary gets bridged to C++ we convert it to a
`StructuredData::Dictionary` that uses a `std::map<ConstString, ObjectSP>`
for storage.
Because `std::map` is an ordered container and ours uses the `ConstString`
type for keys, the thread indices gets converted to strings which makes the
dictionary sorted alphabetically, instead of numerically.
If the ScriptedProcess has 10 threads or more, it causes thread “10”
(and higher) to be after thread “1”, but before thread “2”.
In order to solve this, this sorts the thread info dictionary keys
numerically, before iterating over them to create ScriptedThreads.
rdar://90327854
Differential Revision: https://reviews.llvm.org/D122429
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2022-03-25 14:25:23 -07:00
|
|
|
if (!object_sp)
|
2022-01-18 12:56:42 +01:00
|
|
|
return ScriptedInterface::ErrorWithMessage<bool>(
|
[lldb/Plugin] Sort the ScriptedProcess' thread list before creating threads
With Scripted Processes, in order to create scripted threads, the blueprint
provides a dictionary that have each thread index as the key with the respective
thread instance as the pair value.
In Python, this is fine because a dictionary key can be of any type including
integer types:
```
>>> {1: "one", 2: "two", 10: "ten"}
{1: 'one', 2: 'two', 10: 'ten'}
```
However, when the python dictionary gets bridged to C++ we convert it to a
`StructuredData::Dictionary` that uses a `std::map<ConstString, ObjectSP>`
for storage.
Because `std::map` is an ordered container and ours uses the `ConstString`
type for keys, the thread indices gets converted to strings which makes the
dictionary sorted alphabetically, instead of numerically.
If the ScriptedProcess has 10 threads or more, it causes thread “10”
(and higher) to be after thread “1”, but before thread “2”.
In order to solve this, this sorts the thread info dictionary keys
numerically, before iterating over them to create ScriptedThreads.
rdar://90327854
Differential Revision: https://reviews.llvm.org/D122429
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2022-03-25 14:25:23 -07:00
|
|
|
LLVM_PRETTY_FUNCTION, "Invalid thread info object", error);
|
2022-01-18 12:45:57 +01:00
|
|
|
|
[lldb/Plugin] Sort the ScriptedProcess' thread list before creating threads
With Scripted Processes, in order to create scripted threads, the blueprint
provides a dictionary that have each thread index as the key with the respective
thread instance as the pair value.
In Python, this is fine because a dictionary key can be of any type including
integer types:
```
>>> {1: "one", 2: "two", 10: "ten"}
{1: 'one', 2: 'two', 10: 'ten'}
```
However, when the python dictionary gets bridged to C++ we convert it to a
`StructuredData::Dictionary` that uses a `std::map<ConstString, ObjectSP>`
for storage.
Because `std::map` is an ordered container and ours uses the `ConstString`
type for keys, the thread indices gets converted to strings which makes the
dictionary sorted alphabetically, instead of numerically.
If the ScriptedProcess has 10 threads or more, it causes thread “10”
(and higher) to be after thread “1”, but before thread “2”.
In order to solve this, this sorts the thread info dictionary keys
numerically, before iterating over them to create ScriptedThreads.
rdar://90327854
Differential Revision: https://reviews.llvm.org/D122429
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2022-03-25 14:25:23 -07:00
|
|
|
auto thread_or_error =
|
|
|
|
|
ScriptedThread::Create(*this, object_sp->GetAsGeneric());
|
2022-01-18 12:45:57 +01:00
|
|
|
|
2022-01-18 12:52:24 +01:00
|
|
|
if (!thread_or_error)
|
2022-01-18 12:56:42 +01:00
|
|
|
return ScriptedInterface::ErrorWithMessage<bool>(
|
2022-01-18 12:52:24 +01:00
|
|
|
LLVM_PRETTY_FUNCTION, toString(thread_or_error.takeError()), error);
|
|
|
|
|
|
|
|
|
|
ThreadSP thread_sp = thread_or_error.get();
|
|
|
|
|
lldbassert(thread_sp && "Couldn't initialize scripted thread.");
|
2022-01-18 12:45:57 +01:00
|
|
|
|
|
|
|
|
RegisterContextSP reg_ctx_sp = thread_sp->GetRegisterContext();
|
|
|
|
|
if (!reg_ctx_sp)
|
2022-01-18 12:56:42 +01:00
|
|
|
return ScriptedInterface::ErrorWithMessage<bool>(
|
2022-01-18 12:45:57 +01:00
|
|
|
LLVM_PRETTY_FUNCTION,
|
[lldb/Plugin] Sort the ScriptedProcess' thread list before creating threads
With Scripted Processes, in order to create scripted threads, the blueprint
provides a dictionary that have each thread index as the key with the respective
thread instance as the pair value.
In Python, this is fine because a dictionary key can be of any type including
integer types:
```
>>> {1: "one", 2: "two", 10: "ten"}
{1: 'one', 2: 'two', 10: 'ten'}
```
However, when the python dictionary gets bridged to C++ we convert it to a
`StructuredData::Dictionary` that uses a `std::map<ConstString, ObjectSP>`
for storage.
Because `std::map` is an ordered container and ours uses the `ConstString`
type for keys, the thread indices gets converted to strings which makes the
dictionary sorted alphabetically, instead of numerically.
If the ScriptedProcess has 10 threads or more, it causes thread “10”
(and higher) to be after thread “1”, but before thread “2”.
In order to solve this, this sorts the thread info dictionary keys
numerically, before iterating over them to create ScriptedThreads.
rdar://90327854
Differential Revision: https://reviews.llvm.org/D122429
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2022-03-25 14:25:23 -07:00
|
|
|
llvm::Twine("Invalid Register Context for thread " + llvm::Twine(idx))
|
2022-01-18 12:45:57 +01:00
|
|
|
.str(),
|
|
|
|
|
error);
|
|
|
|
|
|
|
|
|
|
new_thread_list.AddThread(thread_sp);
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
};
|
|
|
|
|
|
[lldb/Plugin] Sort the ScriptedProcess' thread list before creating threads
With Scripted Processes, in order to create scripted threads, the blueprint
provides a dictionary that have each thread index as the key with the respective
thread instance as the pair value.
In Python, this is fine because a dictionary key can be of any type including
integer types:
```
>>> {1: "one", 2: "two", 10: "ten"}
{1: 'one', 2: 'two', 10: 'ten'}
```
However, when the python dictionary gets bridged to C++ we convert it to a
`StructuredData::Dictionary` that uses a `std::map<ConstString, ObjectSP>`
for storage.
Because `std::map` is an ordered container and ours uses the `ConstString`
type for keys, the thread indices gets converted to strings which makes the
dictionary sorted alphabetically, instead of numerically.
If the ScriptedProcess has 10 threads or more, it causes thread “10”
(and higher) to be after thread “1”, but before thread “2”.
In order to solve this, this sorts the thread info dictionary keys
numerically, before iterating over them to create ScriptedThreads.
rdar://90327854
Differential Revision: https://reviews.llvm.org/D122429
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2022-03-25 14:25:23 -07:00
|
|
|
llvm::for_each(sorted_threads, create_scripted_thread);
|
2021-10-06 00:09:20 +00:00
|
|
|
|
2021-07-20 13:00:54 +00:00
|
|
|
return new_thread_list.GetSize(false) > 0;
|
|
|
|
|
}
|
|
|
|
|
|
2021-11-10 19:53:14 +00:00
|
|
|
void ScriptedProcess::RefreshStateAfterStop() {
|
|
|
|
|
// Let all threads recover from stopping and do any clean up based on the
|
|
|
|
|
// previous thread state (if any).
|
2022-02-09 19:04:21 -08:00
|
|
|
m_thread_list.RefreshStateAfterStop();
|
2021-11-10 19:53:14 +00:00
|
|
|
}
|
|
|
|
|
|
2021-07-20 13:00:54 +00:00
|
|
|
bool ScriptedProcess::GetProcessInfo(ProcessInstanceInfo &info) {
|
|
|
|
|
info.Clear();
|
|
|
|
|
info.SetProcessID(GetID());
|
|
|
|
|
info.SetArchitecture(GetArchitecture());
|
|
|
|
|
lldb::ModuleSP module_sp = GetTarget().GetExecutableModule();
|
|
|
|
|
if (module_sp) {
|
|
|
|
|
const bool add_exe_file_as_first_arg = false;
|
|
|
|
|
info.SetExecutableFile(GetTarget().GetExecutableModule()->GetFileSpec(),
|
|
|
|
|
add_exe_file_as_first_arg);
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-04 11:22:32 -08:00
|
|
|
lldb_private::StructuredData::ObjectSP
|
|
|
|
|
ScriptedProcess::GetLoadedDynamicLibrariesInfos() {
|
|
|
|
|
CheckInterpreterAndScriptObject();
|
|
|
|
|
|
|
|
|
|
Status error;
|
|
|
|
|
auto error_with_message = [&error](llvm::StringRef message) {
|
|
|
|
|
return ScriptedInterface::ErrorWithMessage<bool>(LLVM_PRETTY_FUNCTION,
|
|
|
|
|
message.data(), error);
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
StructuredData::ArraySP loaded_images_sp = GetInterface().GetLoadedImages();
|
|
|
|
|
|
|
|
|
|
if (!loaded_images_sp || !loaded_images_sp->GetSize())
|
2022-10-07 16:11:49 -07:00
|
|
|
return ScriptedInterface::ErrorWithMessage<StructuredData::ObjectSP>(
|
2022-03-04 11:22:32 -08:00
|
|
|
LLVM_PRETTY_FUNCTION, "No loaded images.", error);
|
|
|
|
|
|
|
|
|
|
ModuleList module_list;
|
|
|
|
|
Target &target = GetTarget();
|
|
|
|
|
|
|
|
|
|
auto reload_image = [&target, &module_list, &error_with_message](
|
|
|
|
|
StructuredData::Object *obj) -> bool {
|
|
|
|
|
StructuredData::Dictionary *dict = obj->GetAsDictionary();
|
|
|
|
|
|
|
|
|
|
if (!dict)
|
|
|
|
|
return error_with_message("Couldn't cast image object into dictionary.");
|
|
|
|
|
|
|
|
|
|
ModuleSpec module_spec;
|
|
|
|
|
llvm::StringRef value;
|
|
|
|
|
|
|
|
|
|
bool has_path = dict->HasKey("path");
|
|
|
|
|
bool has_uuid = dict->HasKey("uuid");
|
|
|
|
|
if (!has_path && !has_uuid)
|
|
|
|
|
return error_with_message("Dictionary should have key 'path' or 'uuid'");
|
|
|
|
|
if (!dict->HasKey("load_addr"))
|
|
|
|
|
return error_with_message("Dictionary is missing key 'load_addr'");
|
|
|
|
|
|
|
|
|
|
if (has_path) {
|
|
|
|
|
dict->GetValueForKeyAsString("path", value);
|
|
|
|
|
module_spec.GetFileSpec().SetPath(value);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (has_uuid) {
|
|
|
|
|
dict->GetValueForKeyAsString("uuid", value);
|
|
|
|
|
module_spec.GetUUID().SetFromStringRef(value);
|
|
|
|
|
}
|
|
|
|
|
module_spec.GetArchitecture() = target.GetArchitecture();
|
|
|
|
|
|
|
|
|
|
ModuleSP module_sp =
|
|
|
|
|
target.GetOrCreateModule(module_spec, true /* notify */);
|
|
|
|
|
|
|
|
|
|
if (!module_sp)
|
|
|
|
|
return error_with_message("Couldn't create or get module.");
|
|
|
|
|
|
|
|
|
|
lldb::addr_t load_addr = LLDB_INVALID_ADDRESS;
|
|
|
|
|
lldb::addr_t slide = LLDB_INVALID_OFFSET;
|
|
|
|
|
dict->GetValueForKeyAsInteger("load_addr", load_addr);
|
|
|
|
|
dict->GetValueForKeyAsInteger("slide", slide);
|
|
|
|
|
if (load_addr == LLDB_INVALID_ADDRESS)
|
|
|
|
|
return error_with_message(
|
|
|
|
|
"Couldn't get valid load address or slide offset.");
|
|
|
|
|
|
|
|
|
|
if (slide != LLDB_INVALID_OFFSET)
|
|
|
|
|
load_addr += slide;
|
|
|
|
|
|
|
|
|
|
bool changed = false;
|
|
|
|
|
module_sp->SetLoadAddress(target, load_addr, false /*=value_is_offset*/,
|
|
|
|
|
changed);
|
|
|
|
|
|
|
|
|
|
if (!changed && !module_sp->GetObjectFile())
|
|
|
|
|
return error_with_message("Couldn't set the load address for module.");
|
|
|
|
|
|
|
|
|
|
dict->GetValueForKeyAsString("path", value);
|
|
|
|
|
FileSpec objfile(value);
|
|
|
|
|
module_sp->SetFileSpecAndObjectName(objfile, objfile.GetFilename());
|
|
|
|
|
|
|
|
|
|
return module_list.AppendIfNeeded(module_sp);
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
if (!loaded_images_sp->ForEach(reload_image))
|
2022-10-07 16:11:49 -07:00
|
|
|
return ScriptedInterface::ErrorWithMessage<StructuredData::ObjectSP>(
|
2022-03-04 11:22:32 -08:00
|
|
|
LLVM_PRETTY_FUNCTION, "Couldn't reload all images.", error);
|
|
|
|
|
|
|
|
|
|
target.ModulesDidLoad(module_list);
|
|
|
|
|
|
|
|
|
|
return loaded_images_sp;
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-03 14:27:28 -07:00
|
|
|
lldb_private::StructuredData::DictionarySP ScriptedProcess::GetMetadata() {
|
|
|
|
|
CheckInterpreterAndScriptObject();
|
|
|
|
|
|
|
|
|
|
StructuredData::DictionarySP metadata_sp = GetInterface().GetMetadata();
|
|
|
|
|
|
|
|
|
|
Status error;
|
|
|
|
|
if (!metadata_sp || !metadata_sp->GetSize())
|
|
|
|
|
return ScriptedInterface::ErrorWithMessage<StructuredData::DictionarySP>(
|
|
|
|
|
LLVM_PRETTY_FUNCTION, "No metadata.", error);
|
|
|
|
|
|
|
|
|
|
return metadata_sp;
|
|
|
|
|
}
|
|
|
|
|
|
2021-07-20 13:00:54 +00:00
|
|
|
ScriptedProcessInterface &ScriptedProcess::GetInterface() const {
|
|
|
|
|
return m_interpreter->GetScriptedProcessInterface();
|
|
|
|
|
}
|