llvm-project/lldb/source/Target/ThreadPlanTracer.cpp

287 lines
8.0 KiB
C++
Raw Normal View History

//===-- ThreadPlan.cpp ------------------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "lldb/lldb-python.h"
#include "lldb/Target/ThreadPlan.h"
// C Includes
#include <string.h>
// C++ Includes
// Other libraries and framework includes
// Project includes
#include "lldb/Core/ArchSpec.h"
#include "lldb/Core/DataBufferHeap.h"
#include "lldb/Core/Debugger.h"
#include "lldb/Core/Disassembler.h"
#include "lldb/Core/Log.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-30 05:13:06 +08:00
#include "lldb/Core/Module.h"
#include "lldb/Core/State.h"
#include "lldb/Core/Value.h"
#include "lldb/Symbol/TypeList.h"
#include "lldb/Target/RegisterContext.h"
#include "lldb/Target/Thread.h"
#include "lldb/Target/Process.h"
#include "lldb/Target/Target.h"
using namespace lldb;
using namespace lldb_private;
#pragma mark ThreadPlanTracer
ThreadPlanTracer::ThreadPlanTracer (Thread &thread, lldb::StreamSP &stream_sp) :
m_thread (thread),
m_single_step(true),
m_enabled (false),
m_stream_sp (stream_sp)
{
}
ThreadPlanTracer::ThreadPlanTracer (Thread &thread) :
m_thread (thread),
m_single_step(true),
m_enabled (false),
m_stream_sp ()
{
}
Stream *
ThreadPlanTracer::GetLogStream ()
{
if (m_stream_sp.get())
return m_stream_sp.get();
else
{
TargetSP target_sp (m_thread.CalculateTarget());
if (target_sp)
return &target_sp->GetDebugger().GetOutputStream();
}
return NULL;
}
void
ThreadPlanTracer::Log()
{
SymbolContext sc;
bool show_frame_index = false;
bool show_fullpaths = false;
Stream *stream = GetLogStream();
if (stream)
{
m_thread.GetStackFrameAtIndex(0)->Dump (stream, show_frame_index, show_fullpaths);
stream->Printf("\n");
stream->Flush();
}
}
bool
ThreadPlanTracer::TracerExplainsStop ()
{
if (m_enabled && m_single_step)
{
lldb::StopInfoSP stop_info = m_thread.GetStopInfo();
if (stop_info->GetStopReason() == eStopReasonTrace)
return true;
else
return false;
}
else
return false;
}
#pragma mark ThreadPlanAssemblyTracer
ThreadPlanAssemblyTracer::ThreadPlanAssemblyTracer (Thread &thread, lldb::StreamSP &stream_sp) :
ThreadPlanTracer (thread, stream_sp),
m_disassembler_sp (),
m_intptr_type (),
m_register_values ()
{
}
ThreadPlanAssemblyTracer::ThreadPlanAssemblyTracer (Thread &thread) :
ThreadPlanTracer (thread),
m_disassembler_sp (),
m_intptr_type (),
m_register_values ()
{
}
Disassembler *
ThreadPlanAssemblyTracer::GetDisassembler ()
{
if (m_disassembler_sp.get() == NULL)
m_disassembler_sp = Disassembler::FindPlugin(m_thread.GetProcess()->GetTarget().GetArchitecture(), NULL, NULL);
return m_disassembler_sp.get();
}
TypeFromUser
ThreadPlanAssemblyTracer::GetIntPointerType()
{
if (!m_intptr_type.IsValid ())
{
TargetSP target_sp (m_thread.CalculateTarget());
if (target_sp)
{
Module *exe_module = target_sp->GetExecutableModulePointer();
if (exe_module)
{
m_intptr_type = TypeFromUser(exe_module->GetClangASTContext().GetBuiltinTypeForEncodingAndBitSize(eEncodingUint, target_sp->GetArchitecture().GetAddressByteSize() * 8));
}
}
}
return m_intptr_type;
}
ThreadPlanAssemblyTracer::~ThreadPlanAssemblyTracer()
{
}
Fixed issues with RegisterContext classes and the subclasses. There was an issue with the way the UnwindLLDB was handing out RegisterContexts: it was making shared pointers to register contexts and then handing out just the pointers (which would get put into shared pointers in the thread and stack frame classes) and cause double free issues. MallocScribble helped to find these issues after I did some other cleanup. To help avoid any RegisterContext issue in the future, all code that deals with them now returns shared pointers to the register contexts so we don't end up with multiple deletions. Also now that the RegisterContext class doesn't require a stack frame, we patched a memory leak where a StackFrame object was being created and leaked. Made the RegisterContext class not have a pointer to a StackFrame object as one register context class can be used for N inlined stack frames so there is not a 1 - 1 mapping. Updates the ExecutionContextScope part of the RegisterContext class to never return a stack frame to indicate this when it is asked to recreate the execution context. Now register contexts point to the concrete frame using a concrete frame index. Concrete frames are all of the frames that are actually formed on the stack of a thread. These concrete frames can be turned into one or more user visible frames due to inlining. Each inlined stack frame has the exact same register context (shared via shared pointers) as any parent inlined stack frames all the way up to the concrete frame itself. So now the stack frames and the register contexts should behave much better. llvm-svn: 122976
2011-01-07 06:15:06 +08:00
void
ThreadPlanAssemblyTracer::TracingStarted ()
{
Fixed issues with RegisterContext classes and the subclasses. There was an issue with the way the UnwindLLDB was handing out RegisterContexts: it was making shared pointers to register contexts and then handing out just the pointers (which would get put into shared pointers in the thread and stack frame classes) and cause double free issues. MallocScribble helped to find these issues after I did some other cleanup. To help avoid any RegisterContext issue in the future, all code that deals with them now returns shared pointers to the register contexts so we don't end up with multiple deletions. Also now that the RegisterContext class doesn't require a stack frame, we patched a memory leak where a StackFrame object was being created and leaked. Made the RegisterContext class not have a pointer to a StackFrame object as one register context class can be used for N inlined stack frames so there is not a 1 - 1 mapping. Updates the ExecutionContextScope part of the RegisterContext class to never return a stack frame to indicate this when it is asked to recreate the execution context. Now register contexts point to the concrete frame using a concrete frame index. Concrete frames are all of the frames that are actually formed on the stack of a thread. These concrete frames can be turned into one or more user visible frames due to inlining. Each inlined stack frame has the exact same register context (shared via shared pointers) as any parent inlined stack frames all the way up to the concrete frame itself. So now the stack frames and the register contexts should behave much better. llvm-svn: 122976
2011-01-07 06:15:06 +08:00
RegisterContext *reg_ctx = m_thread.GetRegisterContext().get();
if (m_register_values.size() == 0)
m_register_values.resize (reg_ctx->GetRegisterCount());
}
Fixed issues with RegisterContext classes and the subclasses. There was an issue with the way the UnwindLLDB was handing out RegisterContexts: it was making shared pointers to register contexts and then handing out just the pointers (which would get put into shared pointers in the thread and stack frame classes) and cause double free issues. MallocScribble helped to find these issues after I did some other cleanup. To help avoid any RegisterContext issue in the future, all code that deals with them now returns shared pointers to the register contexts so we don't end up with multiple deletions. Also now that the RegisterContext class doesn't require a stack frame, we patched a memory leak where a StackFrame object was being created and leaked. Made the RegisterContext class not have a pointer to a StackFrame object as one register context class can be used for N inlined stack frames so there is not a 1 - 1 mapping. Updates the ExecutionContextScope part of the RegisterContext class to never return a stack frame to indicate this when it is asked to recreate the execution context. Now register contexts point to the concrete frame using a concrete frame index. Concrete frames are all of the frames that are actually formed on the stack of a thread. These concrete frames can be turned into one or more user visible frames due to inlining. Each inlined stack frame has the exact same register context (shared via shared pointers) as any parent inlined stack frames all the way up to the concrete frame itself. So now the stack frames and the register contexts should behave much better. llvm-svn: 122976
2011-01-07 06:15:06 +08:00
void
ThreadPlanAssemblyTracer::TracingEnded ()
{
m_register_values.clear();
}
Fixed issues with RegisterContext classes and the subclasses. There was an issue with the way the UnwindLLDB was handing out RegisterContexts: it was making shared pointers to register contexts and then handing out just the pointers (which would get put into shared pointers in the thread and stack frame classes) and cause double free issues. MallocScribble helped to find these issues after I did some other cleanup. To help avoid any RegisterContext issue in the future, all code that deals with them now returns shared pointers to the register contexts so we don't end up with multiple deletions. Also now that the RegisterContext class doesn't require a stack frame, we patched a memory leak where a StackFrame object was being created and leaked. Made the RegisterContext class not have a pointer to a StackFrame object as one register context class can be used for N inlined stack frames so there is not a 1 - 1 mapping. Updates the ExecutionContextScope part of the RegisterContext class to never return a stack frame to indicate this when it is asked to recreate the execution context. Now register contexts point to the concrete frame using a concrete frame index. Concrete frames are all of the frames that are actually formed on the stack of a thread. These concrete frames can be turned into one or more user visible frames due to inlining. Each inlined stack frame has the exact same register context (shared via shared pointers) as any parent inlined stack frames all the way up to the concrete frame itself. So now the stack frames and the register contexts should behave much better. llvm-svn: 122976
2011-01-07 06:15:06 +08:00
static void
PadOutTo (StreamString &stream, int target)
{
stream.Flush();
int length = stream.GetString().length();
if (length + 1 < target)
Fixed issues with RegisterContext classes and the subclasses. There was an issue with the way the UnwindLLDB was handing out RegisterContexts: it was making shared pointers to register contexts and then handing out just the pointers (which would get put into shared pointers in the thread and stack frame classes) and cause double free issues. MallocScribble helped to find these issues after I did some other cleanup. To help avoid any RegisterContext issue in the future, all code that deals with them now returns shared pointers to the register contexts so we don't end up with multiple deletions. Also now that the RegisterContext class doesn't require a stack frame, we patched a memory leak where a StackFrame object was being created and leaked. Made the RegisterContext class not have a pointer to a StackFrame object as one register context class can be used for N inlined stack frames so there is not a 1 - 1 mapping. Updates the ExecutionContextScope part of the RegisterContext class to never return a stack frame to indicate this when it is asked to recreate the execution context. Now register contexts point to the concrete frame using a concrete frame index. Concrete frames are all of the frames that are actually formed on the stack of a thread. These concrete frames can be turned into one or more user visible frames due to inlining. Each inlined stack frame has the exact same register context (shared via shared pointers) as any parent inlined stack frames all the way up to the concrete frame itself. So now the stack frames and the register contexts should behave much better. llvm-svn: 122976
2011-01-07 06:15:06 +08:00
stream.Printf("%*s", target - (length + 1) + 1, "");
}
Fixed issues with RegisterContext classes and the subclasses. There was an issue with the way the UnwindLLDB was handing out RegisterContexts: it was making shared pointers to register contexts and then handing out just the pointers (which would get put into shared pointers in the thread and stack frame classes) and cause double free issues. MallocScribble helped to find these issues after I did some other cleanup. To help avoid any RegisterContext issue in the future, all code that deals with them now returns shared pointers to the register contexts so we don't end up with multiple deletions. Also now that the RegisterContext class doesn't require a stack frame, we patched a memory leak where a StackFrame object was being created and leaked. Made the RegisterContext class not have a pointer to a StackFrame object as one register context class can be used for N inlined stack frames so there is not a 1 - 1 mapping. Updates the ExecutionContextScope part of the RegisterContext class to never return a stack frame to indicate this when it is asked to recreate the execution context. Now register contexts point to the concrete frame using a concrete frame index. Concrete frames are all of the frames that are actually formed on the stack of a thread. These concrete frames can be turned into one or more user visible frames due to inlining. Each inlined stack frame has the exact same register context (shared via shared pointers) as any parent inlined stack frames all the way up to the concrete frame itself. So now the stack frames and the register contexts should behave much better. llvm-svn: 122976
2011-01-07 06:15:06 +08:00
void
ThreadPlanAssemblyTracer::Log ()
{
Stream *stream = GetLogStream ();
if (!stream)
return;
Fixed issues with RegisterContext classes and the subclasses. There was an issue with the way the UnwindLLDB was handing out RegisterContexts: it was making shared pointers to register contexts and then handing out just the pointers (which would get put into shared pointers in the thread and stack frame classes) and cause double free issues. MallocScribble helped to find these issues after I did some other cleanup. To help avoid any RegisterContext issue in the future, all code that deals with them now returns shared pointers to the register contexts so we don't end up with multiple deletions. Also now that the RegisterContext class doesn't require a stack frame, we patched a memory leak where a StackFrame object was being created and leaked. Made the RegisterContext class not have a pointer to a StackFrame object as one register context class can be used for N inlined stack frames so there is not a 1 - 1 mapping. Updates the ExecutionContextScope part of the RegisterContext class to never return a stack frame to indicate this when it is asked to recreate the execution context. Now register contexts point to the concrete frame using a concrete frame index. Concrete frames are all of the frames that are actually formed on the stack of a thread. These concrete frames can be turned into one or more user visible frames due to inlining. Each inlined stack frame has the exact same register context (shared via shared pointers) as any parent inlined stack frames all the way up to the concrete frame itself. So now the stack frames and the register contexts should behave much better. llvm-svn: 122976
2011-01-07 06:15:06 +08:00
RegisterContext *reg_ctx = m_thread.GetRegisterContext().get();
lldb::addr_t pc = reg_ctx->GetPC();
ProcessSP process_sp (m_thread.GetProcess());
Address pc_addr;
bool addr_valid = false;
uint8_t buffer[16] = {0}; // Must be big enough for any single instruction
addr_valid = process_sp->GetTarget().GetSectionLoadList().ResolveLoadAddress (pc, pc_addr);
pc_addr.Dump(stream, &m_thread, Address::DumpStyleResolvedDescription, Address::DumpStyleModuleWithFileAddress);
stream->PutCString (" ");
Disassembler *disassembler = GetDisassembler();
if (disassembler)
{
Error err;
process_sp->ReadMemory(pc, buffer, sizeof(buffer), err);
if (err.Success())
{
DataExtractor extractor(buffer, sizeof(buffer),
process_sp->GetByteOrder(),
process_sp->GetAddressByteSize());
bool data_from_file = false;
if (addr_valid)
disassembler->DecodeInstructions (pc_addr, extractor, 0, 1, false, data_from_file);
else
disassembler->DecodeInstructions (Address (pc), extractor, 0, 1, false, data_from_file);
InstructionList &instruction_list = disassembler->GetInstructionList();
Added the ability to get the min and max instruction byte size for an architecture into ArchSpec: uint32_t ArchSpec::GetMinimumOpcodeByteSize() const; uint32_t ArchSpec::GetMaximumOpcodeByteSize() const; Added an AddressClass to the Instruction class in Disassembler.h. This allows decoded instructions to know know if they are code, code with alternate ISA (thumb), or even data which can be mixed into code. The instruction does have an address, but it is a good idea to cache this value so we don't have to look it up more than once. Fixed an issue in Opcode::SetOpcodeBytes() where the length wasn't getting set. Changed: bool SymbolContextList::AppendIfUnique (const SymbolContext& sc); To: bool SymbolContextList::AppendIfUnique (const SymbolContext& sc, bool merge_symbol_into_function); This function was typically being used when looking up functions and symbols. Now if you lookup a function, then find the symbol, they can be merged into the same symbol context and not cause multiple symbol contexts to appear in a symbol context list that describes the same function. Fixed the SymbolContext not equal operator which was causing mixed mode disassembly to not work ("disassembler --mixed --name main"). Modified the disassembler classes to know about the fact we know, for a given architecture, what the min and max opcode byte sizes are. The InstructionList class was modified to return the max opcode byte size for all of the instructions in its list. These two fixes means when disassemble a list of instructions and dump them and show the opcode bytes, we can format the output more intelligently when showing opcode bytes. This affects any architectures that have varying opcode byte sizes (x86_64 and i386). Knowing the max opcode byte size also helps us to be able to disassemble N instructions without having to re-read data if we didn't read enough bytes. Added the ability to set the architecture for the disassemble command. This means you can easily cross disassemble data for any supported architecture. I also added the ability to specify "thumb" as an architecture so that we can force disassembly into thumb mode when needed. In GDB this was done using a hack of specifying an odd address when disassembling. I don't want to repeat this hack in LLDB, so the auto detection between ARM and thumb is failing, just specify thumb when disassembling: (lldb) disassemble --arch thumb --name main You can also have data in say an x86_64 file executable and disassemble data as any other supported architecture: % lldb a.out Current executable set to 'a.out' (x86_64). (lldb) b main (lldb) run (lldb) disassemble --arch thumb --count 2 --start-address 0x0000000100001080 --bytes 0x100001080: 0xb580 push {r7, lr} 0x100001082: 0xaf00 add r7, sp, #0 Fixed Target::ReadMemory(...) to be able to deal with Address argument object that isn't section offset. When an address object was supplied that was out on the heap or stack, target read memory would fail. Disassembly uses Target::ReadMemory(...), and the example above where we disassembler thumb opcodes in an x86 binary was failing do to this bug. llvm-svn: 128347
2011-03-27 03:14:58 +08:00
const uint32_t max_opcode_byte_size = instruction_list.GetMaxOpcocdeByteSize();
if (instruction_list.GetSize())
{
const bool show_bytes = true;
const bool show_address = true;
Instruction *instruction = instruction_list.GetInstructionAtIndex(0).get();
instruction->Dump (stream,
Added the ability to get the min and max instruction byte size for an architecture into ArchSpec: uint32_t ArchSpec::GetMinimumOpcodeByteSize() const; uint32_t ArchSpec::GetMaximumOpcodeByteSize() const; Added an AddressClass to the Instruction class in Disassembler.h. This allows decoded instructions to know know if they are code, code with alternate ISA (thumb), or even data which can be mixed into code. The instruction does have an address, but it is a good idea to cache this value so we don't have to look it up more than once. Fixed an issue in Opcode::SetOpcodeBytes() where the length wasn't getting set. Changed: bool SymbolContextList::AppendIfUnique (const SymbolContext& sc); To: bool SymbolContextList::AppendIfUnique (const SymbolContext& sc, bool merge_symbol_into_function); This function was typically being used when looking up functions and symbols. Now if you lookup a function, then find the symbol, they can be merged into the same symbol context and not cause multiple symbol contexts to appear in a symbol context list that describes the same function. Fixed the SymbolContext not equal operator which was causing mixed mode disassembly to not work ("disassembler --mixed --name main"). Modified the disassembler classes to know about the fact we know, for a given architecture, what the min and max opcode byte sizes are. The InstructionList class was modified to return the max opcode byte size for all of the instructions in its list. These two fixes means when disassemble a list of instructions and dump them and show the opcode bytes, we can format the output more intelligently when showing opcode bytes. This affects any architectures that have varying opcode byte sizes (x86_64 and i386). Knowing the max opcode byte size also helps us to be able to disassemble N instructions without having to re-read data if we didn't read enough bytes. Added the ability to set the architecture for the disassemble command. This means you can easily cross disassemble data for any supported architecture. I also added the ability to specify "thumb" as an architecture so that we can force disassembly into thumb mode when needed. In GDB this was done using a hack of specifying an odd address when disassembling. I don't want to repeat this hack in LLDB, so the auto detection between ARM and thumb is failing, just specify thumb when disassembling: (lldb) disassemble --arch thumb --name main You can also have data in say an x86_64 file executable and disassemble data as any other supported architecture: % lldb a.out Current executable set to 'a.out' (x86_64). (lldb) b main (lldb) run (lldb) disassemble --arch thumb --count 2 --start-address 0x0000000100001080 --bytes 0x100001080: 0xb580 push {r7, lr} 0x100001082: 0xaf00 add r7, sp, #0 Fixed Target::ReadMemory(...) to be able to deal with Address argument object that isn't section offset. When an address object was supplied that was out on the heap or stack, target read memory would fail. Disassembly uses Target::ReadMemory(...), and the example above where we disassembler thumb opcodes in an x86 binary was failing do to this bug. llvm-svn: 128347
2011-03-27 03:14:58 +08:00
max_opcode_byte_size,
show_address,
show_bytes,
NULL);
}
}
}
const ABI *abi = process_sp->GetABI().get();
TypeFromUser intptr_type = GetIntPointerType();
if (abi && intptr_type.IsValid())
{
ValueList value_list;
const int num_args = 1;
for (int arg_index = 0; arg_index < num_args; ++arg_index)
{
Value value;
value.SetValueType (Value::eValueTypeScalar);
// value.SetContext (Value::eContextTypeClangType, intptr_type.GetOpaqueQualType());
value.SetClangType (intptr_type);
value_list.PushValue (value);
}
if (abi->GetArgumentValues (m_thread, value_list))
{
for (int arg_index = 0; arg_index < num_args; ++arg_index)
{
stream->Printf("\n\targ[%d]=%llx", arg_index, value_list.GetValueAtIndex(arg_index)->GetScalar().ULongLong());
if (arg_index + 1 < num_args)
stream->PutCString (", ");
}
}
}
RegisterValue reg_value;
for (uint32_t reg_num = 0, num_registers = reg_ctx->GetRegisterCount();
reg_num < num_registers;
++reg_num)
{
const RegisterInfo *reg_info = reg_ctx->GetRegisterInfoAtIndex(reg_num);
if (reg_ctx->ReadRegister (reg_info, reg_value))
{
assert (reg_num < m_register_values.size());
if (m_register_values[reg_num].GetType() == RegisterValue::eTypeInvalid ||
reg_value != m_register_values[reg_num])
{
if (reg_value.GetType() != RegisterValue::eTypeInvalid)
{
stream->PutCString ("\n\t");
reg_value.Dump(stream, reg_info, true, false, eFormatDefault);
}
}
m_register_values[reg_num] = reg_value;
}
}
stream->EOL();
stream->Flush();
}