llvm-project/lldb/source/API/SBInstruction.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

384 lines
13 KiB
C++
Raw Normal View History

//===-- SBInstruction.cpp ---------------------------------------*- C++ -*-===//
//
// 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 "lldb/API/SBInstruction.h"
#include "SBReproducerPrivate.h"
#include "lldb/API/SBAddress.h"
#include "lldb/API/SBFrame.h"
#include "lldb/API/SBFile.h"
#include "lldb/API/SBInstruction.h"
#include "lldb/API/SBStream.h"
#include "lldb/API/SBTarget.h"
#include "lldb/Core/Disassembler.h"
#include "lldb/Core/EmulateInstruction.h"
#include "lldb/Core/Module.h"
#include "lldb/Core/StreamFile.h"
#include "lldb/Host/HostInfo.h"
#include "lldb/Target/ExecutionContext.h"
#include "lldb/Target/StackFrame.h"
#include "lldb/Target/Target.h"
#include "lldb/Utility/ArchSpec.h"
#include "lldb/Utility/DataBufferHeap.h"
#include "lldb/Utility/DataExtractor.h"
#include <memory>
// We recently fixed a leak in one of the Instruction subclasses where the
// instruction will only hold a weak reference to the disassembler to avoid a
// cycle that was keeping both objects alive (leak) and we need the
// InstructionImpl class to make sure our public API behaves as users would
// expect. Calls in our public API allow clients to do things like:
//
// 1 lldb::SBInstruction inst;
// 2 inst = target.ReadInstructions(pc, 1).GetInstructionAtIndex(0)
// 3 if (inst.DoesBranch())
// 4 ...
//
// There was a temporary lldb::DisassemblerSP object created in the
// SBInstructionList that was returned by lldb.target.ReadInstructions() that
// will go away after line 2 but the "inst" object should be able to still
// answer questions about itself. So we make sure that any SBInstruction
// objects that are given out have a strong reference to the disassembler and
// the instruction so that the object can live and successfully respond to all
// queries.
class InstructionImpl {
public:
InstructionImpl(const lldb::DisassemblerSP &disasm_sp,
const lldb::InstructionSP &inst_sp)
: m_disasm_sp(disasm_sp), m_inst_sp(inst_sp) {}
lldb::InstructionSP GetSP() const { return m_inst_sp; }
bool IsValid() const { return (bool)m_inst_sp; }
protected:
lldb::DisassemblerSP m_disasm_sp; // Can be empty/invalid
lldb::InstructionSP m_inst_sp;
};
using namespace lldb;
using namespace lldb_private;
SBInstruction::SBInstruction() : m_opaque_sp() {
LLDB_RECORD_CONSTRUCTOR_NO_ARGS(SBInstruction);
}
SBInstruction::SBInstruction(const lldb::DisassemblerSP &disasm_sp,
const lldb::InstructionSP &inst_sp)
: m_opaque_sp(new InstructionImpl(disasm_sp, inst_sp)) {}
SBInstruction::SBInstruction(const SBInstruction &rhs)
: m_opaque_sp(rhs.m_opaque_sp) {
LLDB_RECORD_CONSTRUCTOR(SBInstruction, (const lldb::SBInstruction &), rhs);
}
const SBInstruction &SBInstruction::operator=(const SBInstruction &rhs) {
LLDB_RECORD_METHOD(const lldb::SBInstruction &,
SBInstruction, operator=,(const lldb::SBInstruction &),
rhs);
if (this != &rhs)
m_opaque_sp = rhs.m_opaque_sp;
return LLDB_RECORD_RESULT(*this);
}
SBInstruction::~SBInstruction() {}
bool SBInstruction::IsValid() {
LLDB_RECORD_METHOD_NO_ARGS(bool, SBInstruction, IsValid);
return this->operator bool();
}
SBInstruction::operator bool() const {
LLDB_RECORD_METHOD_CONST_NO_ARGS(bool, SBInstruction, operator bool);
return m_opaque_sp && m_opaque_sp->IsValid();
}
SBAddress SBInstruction::GetAddress() {
LLDB_RECORD_METHOD_NO_ARGS(lldb::SBAddress, SBInstruction, GetAddress);
SBAddress sb_addr;
lldb::InstructionSP inst_sp(GetOpaque());
if (inst_sp && inst_sp->GetAddress().IsValid())
sb_addr.SetAddress(&inst_sp->GetAddress());
return LLDB_RECORD_RESULT(sb_addr);
}
const char *SBInstruction::GetMnemonic(SBTarget target) {
LLDB_RECORD_METHOD(const char *, SBInstruction, GetMnemonic, (lldb::SBTarget),
target);
lldb::InstructionSP inst_sp(GetOpaque());
if (inst_sp) {
ExecutionContext exe_ctx;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 07:41:31 +00:00
TargetSP target_sp(target.GetSP());
std::unique_lock<std::recursive_mutex> lock;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 07:41:31 +00:00
if (target_sp) {
lock = std::unique_lock<std::recursive_mutex>(target_sp->GetAPIMutex());
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 07:41:31 +00:00
target_sp->CalculateExecutionContext(exe_ctx);
exe_ctx.SetProcessSP(target_sp->GetProcessSP());
}
return inst_sp->GetMnemonic(&exe_ctx);
}
return nullptr;
}
const char *SBInstruction::GetOperands(SBTarget target) {
LLDB_RECORD_METHOD(const char *, SBInstruction, GetOperands, (lldb::SBTarget),
target);
lldb::InstructionSP inst_sp(GetOpaque());
if (inst_sp) {
ExecutionContext exe_ctx;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 07:41:31 +00:00
TargetSP target_sp(target.GetSP());
std::unique_lock<std::recursive_mutex> lock;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 07:41:31 +00:00
if (target_sp) {
lock = std::unique_lock<std::recursive_mutex>(target_sp->GetAPIMutex());
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 07:41:31 +00:00
target_sp->CalculateExecutionContext(exe_ctx);
exe_ctx.SetProcessSP(target_sp->GetProcessSP());
}
return inst_sp->GetOperands(&exe_ctx);
}
return nullptr;
}
const char *SBInstruction::GetComment(SBTarget target) {
LLDB_RECORD_METHOD(const char *, SBInstruction, GetComment, (lldb::SBTarget),
target);
lldb::InstructionSP inst_sp(GetOpaque());
if (inst_sp) {
ExecutionContext exe_ctx;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 07:41:31 +00:00
TargetSP target_sp(target.GetSP());
std::unique_lock<std::recursive_mutex> lock;
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 07:41:31 +00:00
if (target_sp) {
lock = std::unique_lock<std::recursive_mutex>(target_sp->GetAPIMutex());
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 07:41:31 +00:00
target_sp->CalculateExecutionContext(exe_ctx);
exe_ctx.SetProcessSP(target_sp->GetProcessSP());
}
return inst_sp->GetComment(&exe_ctx);
}
return nullptr;
}
size_t SBInstruction::GetByteSize() {
LLDB_RECORD_METHOD_NO_ARGS(size_t, SBInstruction, GetByteSize);
lldb::InstructionSP inst_sp(GetOpaque());
if (inst_sp)
return inst_sp->GetOpcode().GetByteSize();
return 0;
}
SBData SBInstruction::GetData(SBTarget target) {
LLDB_RECORD_METHOD(lldb::SBData, SBInstruction, GetData, (lldb::SBTarget),
target);
lldb::SBData sb_data;
lldb::InstructionSP inst_sp(GetOpaque());
if (inst_sp) {
DataExtractorSP data_extractor_sp(new DataExtractor());
if (inst_sp->GetData(*data_extractor_sp)) {
sb_data.SetOpaque(data_extractor_sp);
}
}
return LLDB_RECORD_RESULT(sb_data);
}
bool SBInstruction::DoesBranch() {
LLDB_RECORD_METHOD_NO_ARGS(bool, SBInstruction, DoesBranch);
lldb::InstructionSP inst_sp(GetOpaque());
if (inst_sp)
return inst_sp->DoesBranch();
return false;
}
bool SBInstruction::HasDelaySlot() {
LLDB_RECORD_METHOD_NO_ARGS(bool, SBInstruction, HasDelaySlot);
lldb::InstructionSP inst_sp(GetOpaque());
if (inst_sp)
return inst_sp->HasDelaySlot();
return false;
}
bool SBInstruction::CanSetBreakpoint() {
LLDB_RECORD_METHOD_NO_ARGS(bool, SBInstruction, CanSetBreakpoint);
lldb::InstructionSP inst_sp(GetOpaque());
if (inst_sp)
return inst_sp->CanSetBreakpoint();
return false;
}
lldb::InstructionSP SBInstruction::GetOpaque() {
if (m_opaque_sp)
return m_opaque_sp->GetSP();
else
return lldb::InstructionSP();
}
void SBInstruction::SetOpaque(const lldb::DisassemblerSP &disasm_sp,
const lldb::InstructionSP &inst_sp) {
m_opaque_sp = std::make_shared<InstructionImpl>(disasm_sp, inst_sp);
}
bool SBInstruction::GetDescription(lldb::SBStream &s) {
LLDB_RECORD_METHOD(bool, SBInstruction, GetDescription, (lldb::SBStream &),
s);
lldb::InstructionSP inst_sp(GetOpaque());
if (inst_sp) {
SymbolContext sc;
const Address &addr = inst_sp->GetAddress();
ModuleSP module_sp(addr.GetModule());
if (module_sp)
module_sp->ResolveSymbolContextForAddress(addr, eSymbolContextEverything,
sc);
// Use the "ref()" instead of the "get()" accessor in case the SBStream
// didn't have a stream already created, one will get created...
Get rid of Debugger::FormatPrompt() and replace it with the new FormatEntity class. Why? Debugger::FormatPrompt() would run through the format prompt every time and parse it and emit it piece by piece. It also did formatting differently depending on which key/value pair it was parsing. The new code improves on this with the following features: 1 - Allow format strings to be parsed into a FormatEntity::Entry which can contain multiple child FormatEntity::Entry objects. This FormatEntity::Entry is a parsed version of what was previously always done in Debugger::FormatPrompt() so it is more efficient to emit formatted strings using the new parsed FormatEntity::Entry. 2 - Allows errors in format strings to be shown immediately when setting the settings (frame-format, thread-format, disassembly-format 3 - Allows auto completion by implementing a new OptionValueFormatEntity and switching frame-format, thread-format, and disassembly-format settings over to using it. 4 - The FormatEntity::Entry for each of the frame-format, thread-format, disassembly-format settings only replaces the old one if the format parses correctly 5 - Combines all consecutive string values together for efficient output. This means all "${ansi.*}" keys and all desensitized characters like "\n" "\t" "\0721" "\x23" will get combined with their previous strings 6 - ${*.script:} (like "${var.script:mymodule.my_var_function}") have all been switched over to use ${script.*:} "${script.var:mymodule.my_var_function}") to make the format easier to parse as I don't believe anyone was using these format string power user features. 7 - All key values pairs are defined in simple C arrays of entries so it is much easier to add new entries. These changes pave the way for subsequent modifications where we can modify formats to do more (like control the width of value strings can do more and add more functionality more easily like string formatting to control the width, printf formats and more). llvm-svn: 228207
2015-02-04 22:00:53 +00:00
FormatEntity::Entry format;
FormatEntity::Parse("${addr}: ", format);
inst_sp->Dump(&s.ref(), 0, true, false, nullptr, &sc, nullptr, &format, 0);
return true;
}
return false;
}
void SBInstruction::Print(FILE *outp) {
LLDB_RECORD_METHOD(void, SBInstruction, Print, (FILE *), outp);
FileSP out = std::make_shared<NativeFile>(outp, /*take_ownership=*/false);
Print(out);
}
void SBInstruction::Print(SBFile out) {
LLDB_RECORD_METHOD(void, SBInstruction, Print, (SBFile), out);
Print(out.m_opaque_sp);
}
void SBInstruction::Print(FileSP out_sp) {
LLDB_RECORD_METHOD(void, SBInstruction, Print, (FileSP), out_sp);
if (!out_sp || !out_sp->IsValid())
return;
lldb::InstructionSP inst_sp(GetOpaque());
if (inst_sp) {
SymbolContext sc;
const Address &addr = inst_sp->GetAddress();
ModuleSP module_sp(addr.GetModule());
if (module_sp)
module_sp->ResolveSymbolContextForAddress(addr, eSymbolContextEverything,
sc);
StreamFile out_stream(out_sp);
Get rid of Debugger::FormatPrompt() and replace it with the new FormatEntity class. Why? Debugger::FormatPrompt() would run through the format prompt every time and parse it and emit it piece by piece. It also did formatting differently depending on which key/value pair it was parsing. The new code improves on this with the following features: 1 - Allow format strings to be parsed into a FormatEntity::Entry which can contain multiple child FormatEntity::Entry objects. This FormatEntity::Entry is a parsed version of what was previously always done in Debugger::FormatPrompt() so it is more efficient to emit formatted strings using the new parsed FormatEntity::Entry. 2 - Allows errors in format strings to be shown immediately when setting the settings (frame-format, thread-format, disassembly-format 3 - Allows auto completion by implementing a new OptionValueFormatEntity and switching frame-format, thread-format, and disassembly-format settings over to using it. 4 - The FormatEntity::Entry for each of the frame-format, thread-format, disassembly-format settings only replaces the old one if the format parses correctly 5 - Combines all consecutive string values together for efficient output. This means all "${ansi.*}" keys and all desensitized characters like "\n" "\t" "\0721" "\x23" will get combined with their previous strings 6 - ${*.script:} (like "${var.script:mymodule.my_var_function}") have all been switched over to use ${script.*:} "${script.var:mymodule.my_var_function}") to make the format easier to parse as I don't believe anyone was using these format string power user features. 7 - All key values pairs are defined in simple C arrays of entries so it is much easier to add new entries. These changes pave the way for subsequent modifications where we can modify formats to do more (like control the width of value strings can do more and add more functionality more easily like string formatting to control the width, printf formats and more). llvm-svn: 228207
2015-02-04 22:00:53 +00:00
FormatEntity::Entry format;
FormatEntity::Parse("${addr}: ", format);
inst_sp->Dump(&out_stream, 0, true, false, nullptr, &sc, nullptr, &format,
0);
}
}
Changed the emulate instruction function to take emulate options which are defined as enumerations. Current bits include: eEmulateInstructionOptionAutoAdvancePC eEmulateInstructionOptionIgnoreConditions Modified the EmulateInstruction class to have a few more pure virtuals that can help clients understand how many instructions the emulator can handle: virtual bool SupportsEmulatingIntructionsOfType (InstructionType inst_type) = 0; Where instruction types are defined as: //------------------------------------------------------------------ /// Instruction types //------------------------------------------------------------------ typedef enum InstructionType { eInstructionTypeAny, // Support for any instructions at all (at least one) eInstructionTypePrologueEpilogue, // All prologue and epilogue instructons that push and pop register values and modify sp/fp eInstructionTypePCModifying, // Any instruction that modifies the program counter/instruction pointer eInstructionTypeAll // All instructions of any kind } InstructionType; This allows use to tell what an emulator can do and also allows us to request these abilities when we are finding the plug-in interface. Added the ability for an EmulateInstruction class to get the register names for any registers that are part of the emulation. This helps with being able to dump and log effectively. The UnwindAssembly class now stores the architecture it was created with in case it is needed later in the unwinding process. Added a function that can tell us DWARF register names for ARM that goes along with the source/Utility/ARM_DWARF_Registers.h file: source/Utility/ARM_DWARF_Registers.c Took some of plug-ins out of the lldb_private namespace. llvm-svn: 130189
2011-04-26 04:39:08 +00:00
bool SBInstruction::EmulateWithFrame(lldb::SBFrame &frame,
uint32_t evaluate_options) {
LLDB_RECORD_METHOD(bool, SBInstruction, EmulateWithFrame,
(lldb::SBFrame &, uint32_t), frame, evaluate_options);
lldb::InstructionSP inst_sp(GetOpaque());
if (inst_sp) {
lldb::StackFrameSP frame_sp(frame.GetFrameSP());
SBFrame is now threadsafe using some extra tricks. One issue is that stack frames might go away (the object itself, not the actual logical frame) when we are single stepping due to the way we currently sometimes end up flushing frames when stepping in/out/over. They later will come back to life represented by another object yet they have the same StackID. Now when you get a lldb::SBFrame object, it will track the frame it is initialized with until the thread goes away or the StackID no longer exists in the stack for the thread it was created on. It uses a weak_ptr to both the frame and thread and also stores the StackID. These three items allow us to determine when the stack frame object has gone away (the weak_ptr will be NULL) and allows us to find the correct frame again. In our test suite we had such cases where we were just getting lucky when something like this happened: 1 - stop at breakpoint 2 - get first frame in thread where we stopped 3 - run an expression that causes the program to JIT and run code 4 - run more expressions on the frame from step 2 which was very very luckily still around inside a shared pointer, yet, not part of the current thread (a new stack frame object had appeared with the same stack ID and depth). We now avoid all such issues and properly keep up to date, or we start returning errors when the frame doesn't exist and always responds with invalid answers. Also fixed the UserSettingsController (not going to rewrite this just yet) so that it doesn't crash on shutdown. Using weak_ptr's came in real handy to track when the master controller has already gone away and this allowed me to pull out the previous NotifyOwnerIsShuttingDown() patch as it is no longer needed. llvm-svn: 149231
2012-01-30 07:41:31 +00:00
if (frame_sp) {
lldb_private::ExecutionContext exe_ctx;
frame_sp->CalculateExecutionContext(exe_ctx);
lldb_private::Target *target = exe_ctx.GetTargetPtr();
lldb_private::ArchSpec arch = target->GetArchitecture();
return inst_sp->Emulate(
arch, evaluate_options, (void *)frame_sp.get(),
&lldb_private::EmulateInstruction::ReadMemoryFrame,
&lldb_private::EmulateInstruction::WriteMemoryFrame,
&lldb_private::EmulateInstruction::ReadRegisterFrame,
&lldb_private::EmulateInstruction::WriteRegisterFrame);
}
}
return false;
}
bool SBInstruction::DumpEmulation(const char *triple) {
LLDB_RECORD_METHOD(bool, SBInstruction, DumpEmulation, (const char *),
triple);
lldb::InstructionSP inst_sp(GetOpaque());
if (inst_sp && triple) {
return inst_sp->DumpEmulation(HostInfo::GetAugmentedArchSpec(triple));
}
return false;
}
bool SBInstruction::TestEmulation(lldb::SBStream &output_stream,
const char *test_file) {
LLDB_RECORD_METHOD(bool, SBInstruction, TestEmulation,
(lldb::SBStream &, const char *), output_stream,
test_file);
if (!m_opaque_sp)
SetOpaque(lldb::DisassemblerSP(),
lldb::InstructionSP(new PseudoInstruction()));
lldb::InstructionSP inst_sp(GetOpaque());
if (inst_sp)
return inst_sp->TestEmulation(output_stream.get(), test_file);
return false;
}
namespace lldb_private {
namespace repro {
template <>
void RegisterMethods<SBInstruction>(Registry &R) {
LLDB_REGISTER_CONSTRUCTOR(SBInstruction, ());
LLDB_REGISTER_CONSTRUCTOR(SBInstruction, (const lldb::SBInstruction &));
LLDB_REGISTER_METHOD(
const lldb::SBInstruction &,
SBInstruction, operator=,(const lldb::SBInstruction &));
LLDB_REGISTER_METHOD(bool, SBInstruction, IsValid, ());
LLDB_REGISTER_METHOD_CONST(bool, SBInstruction, operator bool, ());
LLDB_REGISTER_METHOD(lldb::SBAddress, SBInstruction, GetAddress, ());
LLDB_REGISTER_METHOD(const char *, SBInstruction, GetMnemonic,
(lldb::SBTarget));
LLDB_REGISTER_METHOD(const char *, SBInstruction, GetOperands,
(lldb::SBTarget));
LLDB_REGISTER_METHOD(const char *, SBInstruction, GetComment,
(lldb::SBTarget));
LLDB_REGISTER_METHOD(size_t, SBInstruction, GetByteSize, ());
LLDB_REGISTER_METHOD(lldb::SBData, SBInstruction, GetData,
(lldb::SBTarget));
LLDB_REGISTER_METHOD(bool, SBInstruction, DoesBranch, ());
LLDB_REGISTER_METHOD(bool, SBInstruction, HasDelaySlot, ());
LLDB_REGISTER_METHOD(bool, SBInstruction, CanSetBreakpoint, ());
LLDB_REGISTER_METHOD(bool, SBInstruction, GetDescription,
(lldb::SBStream &));
LLDB_REGISTER_METHOD(void, SBInstruction, Print, (FILE *));
LLDB_REGISTER_METHOD(void, SBInstruction, Print, (SBFile));
LLDB_REGISTER_METHOD(void, SBInstruction, Print, (FileSP));
LLDB_REGISTER_METHOD(bool, SBInstruction, EmulateWithFrame,
(lldb::SBFrame &, uint32_t));
LLDB_REGISTER_METHOD(bool, SBInstruction, DumpEmulation, (const char *));
LLDB_REGISTER_METHOD(bool, SBInstruction, TestEmulation,
(lldb::SBStream &, const char *));
}
}
}