maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp

273 lines
8.9 KiB
C++
Raw Normal View History

Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//===-- UnwindMacOSXFrameBackchain.cpp --------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
// C Includes
// C++ Includes
// Other libraries and framework includes
// Project includes
#include "lldb/Core/ArchSpec.h"
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr objects for the backlink to the lldb_private::Process. The issues we were running into before was someone was holding onto a shared pointer to a lldb_private::Thread for too long, and the lldb_private::Process parent object would get destroyed and the lldb_private::Thread had a "Process &m_process" member which would just treat whatever memory that used to be a Process as a valid Process. This was mostly happening for lldb_private::StackFrame objects that had a member like "Thread &m_thread". So this completes the internal strong/weak changes. Documented the ExecutionContext and ExecutionContextRef classes so that our LLDB developers can understand when and where to use ExecutionContext and ExecutionContextRef objects. llvm-svn: 151009
2012-02-21 08:09:25 +08:00
#include "lldb/Target/ExecutionContext.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Target/Process.h"
#include "lldb/Target/Target.h"
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr objects for the backlink to the lldb_private::Process. The issues we were running into before was someone was holding onto a shared pointer to a lldb_private::Thread for too long, and the lldb_private::Process parent object would get destroyed and the lldb_private::Thread had a "Process &m_process" member which would just treat whatever memory that used to be a Process as a valid Process. This was mostly happening for lldb_private::StackFrame objects that had a member like "Thread &m_thread". So this completes the internal strong/weak changes. Documented the ExecutionContext and ExecutionContextRef classes so that our LLDB developers can understand when and where to use ExecutionContext and ExecutionContextRef objects. llvm-svn: 151009
2012-02-21 08:09:25 +08:00
#include "lldb/Target/Thread.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "RegisterContextMacOSXFrameBackchain.h"
using namespace lldb;
using namespace lldb_private;
UnwindMacOSXFrameBackchain::UnwindMacOSXFrameBackchain (Thread &thread) :
Unwind (thread),
m_cursors()
{
}
uint32_t
Lock the Unwinder before accessing it. llvm-svn: 142632
2011-10-21 09:49:48 +08:00
UnwindMacOSXFrameBackchain::DoGetFrameCount()
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
if (m_cursors.empty())
{
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr objects for the backlink to the lldb_private::Process. The issues we were running into before was someone was holding onto a shared pointer to a lldb_private::Thread for too long, and the lldb_private::Process parent object would get destroyed and the lldb_private::Thread had a "Process &m_process" member which would just treat whatever memory that used to be a Process as a valid Process. This was mostly happening for lldb_private::StackFrame objects that had a member like "Thread &m_thread". So this completes the internal strong/weak changes. Documented the ExecutionContext and ExecutionContextRef classes so that our LLDB developers can understand when and where to use ExecutionContext and ExecutionContextRef objects. llvm-svn: 151009
2012-02-21 08:09:25 +08:00
ExecutionContext exe_ctx (m_thread.shared_from_this());
Target *target = exe_ctx.GetTargetPtr();
if (target)
{
const ArchSpec& target_arch = target->GetArchitecture ();
// Frame zero should always be supplied by the thread...
exe_ctx.SetFrameSP (m_thread.GetStackFrameAtIndex (0));
if (target_arch.GetAddressByteSize() == 8)
GetStackFrameData_x86_64 (exe_ctx);
else
GetStackFrameData_i386 (exe_ctx);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
return m_cursors.size();
}
bool
Lock the Unwinder before accessing it. llvm-svn: 142632
2011-10-21 09:49:48 +08:00
UnwindMacOSXFrameBackchain::DoGetFrameInfoAtIndex (uint32_t idx, addr_t& cfa, addr_t& pc)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
const uint32_t frame_count = GetFrameCount();
if (idx < frame_count)
{
if (m_cursors[idx].pc == LLDB_INVALID_ADDRESS)
return false;
if (m_cursors[idx].fp == LLDB_INVALID_ADDRESS)
return false;
pc = m_cursors[idx].pc;
cfa = m_cursors[idx].fp;
return true;
}
return false;
}
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
lldb::RegisterContextSP
Lock the Unwinder before accessing it. llvm-svn: 142632
2011-10-21 09:49:48 +08:00
UnwindMacOSXFrameBackchain::DoCreateRegisterContextForFrame (StackFrame *frame)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
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
lldb::RegisterContextSP reg_ctx_sp;
uint32_t concrete_idx = frame->GetConcreteFrameIndex ();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
const uint32_t frame_count = GetFrameCount();
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
if (concrete_idx < frame_count)
reg_ctx_sp.reset (new RegisterContextMacOSXFrameBackchain (m_thread, concrete_idx, m_cursors[concrete_idx]));
return reg_ctx_sp;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
size_t
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr objects for the backlink to the lldb_private::Process. The issues we were running into before was someone was holding onto a shared pointer to a lldb_private::Thread for too long, and the lldb_private::Process parent object would get destroyed and the lldb_private::Thread had a "Process &m_process" member which would just treat whatever memory that used to be a Process as a valid Process. This was mostly happening for lldb_private::StackFrame objects that had a member like "Thread &m_thread". So this completes the internal strong/weak changes. Documented the ExecutionContext and ExecutionContextRef classes so that our LLDB developers can understand when and where to use ExecutionContext and ExecutionContextRef objects. llvm-svn: 151009
2012-02-21 08:09:25 +08:00
UnwindMacOSXFrameBackchain::GetStackFrameData_i386 (const ExecutionContext &exe_ctx)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
m_cursors.clear();
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr objects for the backlink to the lldb_private::Process. The issues we were running into before was someone was holding onto a shared pointer to a lldb_private::Thread for too long, and the lldb_private::Process parent object would get destroyed and the lldb_private::Thread had a "Process &m_process" member which would just treat whatever memory that used to be a Process as a valid Process. This was mostly happening for lldb_private::StackFrame objects that had a member like "Thread &m_thread". So this completes the internal strong/weak changes. Documented the ExecutionContext and ExecutionContextRef classes so that our LLDB developers can understand when and where to use ExecutionContext and ExecutionContextRef objects. llvm-svn: 151009
2012-02-21 08:09:25 +08:00
StackFrame *first_frame = exe_ctx.GetFramePtr();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr objects for the backlink to the lldb_private::Process. The issues we were running into before was someone was holding onto a shared pointer to a lldb_private::Thread for too long, and the lldb_private::Process parent object would get destroyed and the lldb_private::Thread had a "Process &m_process" member which would just treat whatever memory that used to be a Process as a valid Process. This was mostly happening for lldb_private::StackFrame objects that had a member like "Thread &m_thread". So this completes the internal strong/weak changes. Documented the ExecutionContext and ExecutionContextRef classes so that our LLDB developers can understand when and where to use ExecutionContext and ExecutionContextRef objects. llvm-svn: 151009
2012-02-21 08:09:25 +08:00
Process *process = exe_ctx.GetProcessPtr();
if (process == NULL)
return 0;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
std::pair<lldb::addr_t, lldb::addr_t> fp_pc_pair;
typedef fixups, patch from Jean-Daniel Dupas. llvm-svn: 107794
2010-07-08 01:07:17 +08:00
struct Frame_i386
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
uint32_t fp;
uint32_t pc;
};
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();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
assert (reg_ctx);
Cursor cursor;
cursor.pc = reg_ctx->GetPC (LLDB_INVALID_ADDRESS);
cursor.fp = reg_ctx->GetFP (0);
Remove a ton of implicit narrowing conversions for C++11 compatibility. llvm-svn: 151071
2012-02-22 02:37:14 +08:00
Frame_i386 frame = { static_cast<uint32_t>(cursor.fp), static_cast<uint32_t>(cursor.pc) };
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_cursors.push_back(cursor);
const size_t k_frame_size = sizeof(frame);
Error error;
while (frame.fp != 0 && frame.pc != 0 && ((frame.fp & 7) == 0))
{
// Read both the FP and PC (8 bytes)
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr objects for the backlink to the lldb_private::Process. The issues we were running into before was someone was holding onto a shared pointer to a lldb_private::Thread for too long, and the lldb_private::Process parent object would get destroyed and the lldb_private::Thread had a "Process &m_process" member which would just treat whatever memory that used to be a Process as a valid Process. This was mostly happening for lldb_private::StackFrame objects that had a member like "Thread &m_thread". So this completes the internal strong/weak changes. Documented the ExecutionContext and ExecutionContextRef classes so that our LLDB developers can understand when and where to use ExecutionContext and ExecutionContextRef objects. llvm-svn: 151009
2012-02-21 08:09:25 +08:00
if (process->ReadMemory (frame.fp, &frame.fp, k_frame_size, error) != k_frame_size)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
break;
if (frame.pc >= 0x1000)
{
cursor.pc = frame.pc;
cursor.fp = frame.fp;
m_cursors.push_back (cursor);
}
}
if (!m_cursors.empty())
{
lldb::addr_t first_frame_pc = m_cursors.front().pc;
if (first_frame_pc != LLDB_INVALID_ADDRESS)
{
const uint32_t resolve_scope = eSymbolContextModule |
eSymbolContextCompUnit |
eSymbolContextFunction |
eSymbolContextSymbol;
SymbolContext first_frame_sc (first_frame->GetSymbolContext(resolve_scope));
const AddressRange *addr_range_ptr = NULL;
<rdar://problem/10997402> This fix really needed to happen as a previous fix I had submitted for calculating symbol sizes made many symbols appear to have zero size since the function that was calculating the symbol size was calling another function that would cause the calculation to happen again. This resulted in some symbols having zero size when they shouldn't. This could then cause infinite stack traces and many other side affects. llvm-svn: 152244
2012-03-08 05:03:09 +08:00
AddressRange range;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (first_frame_sc.function)
addr_range_ptr = &first_frame_sc.function->GetAddressRange();
else if (first_frame_sc.symbol)
<rdar://problem/10997402> This fix really needed to happen as a previous fix I had submitted for calculating symbol sizes made many symbols appear to have zero size since the function that was calculating the symbol size was calling another function that would cause the calculation to happen again. This resulted in some symbols having zero size when they shouldn't. This could then cause infinite stack traces and many other side affects. llvm-svn: 152244
2012-03-08 05:03:09 +08:00
{
range.GetBaseAddress() = first_frame_sc.symbol->GetAddress();
range.SetByteSize (first_frame_sc.symbol->GetByteSize());
addr_range_ptr = &range;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (addr_range_ptr)
{
Got a lot of the kinks worked out in the inline support after debugging more complex inlined examples. StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()". This is because inlined frames will have a PC value that is the same as the concrete frame that owns the inlined frame, yet the code locations for the frame can be different. We also need to be able to get the real PC value for a given frame so that variables evaluate correctly. To get the actual PC value for a frame you can use: addr_t pc = frame->GetRegisterContext()->GetPC(); Some issues with the StackFrame stomping on its own symbol context were resolved which were causing the information to change for a frame when the stack ID was calculated. Also the StackFrame will now correctly store the symbol context resolve flags for any extra bits of information that were looked up (if you ask for a block only and you find one, you will alwasy have the compile unit and function). llvm-svn: 111964
2010-08-25 05:05:24 +08:00
if (first_frame->GetFrameCodeAddress() == addr_range_ptr->GetBaseAddress())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
// We are at the first instruction, so we can recover the
// previous PC by dereferencing the SP
lldb::addr_t first_frame_sp = reg_ctx->GetSP (0);
// Read the real second frame return address into frame.pc
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr objects for the backlink to the lldb_private::Process. The issues we were running into before was someone was holding onto a shared pointer to a lldb_private::Thread for too long, and the lldb_private::Process parent object would get destroyed and the lldb_private::Thread had a "Process &m_process" member which would just treat whatever memory that used to be a Process as a valid Process. This was mostly happening for lldb_private::StackFrame objects that had a member like "Thread &m_thread". So this completes the internal strong/weak changes. Documented the ExecutionContext and ExecutionContextRef classes so that our LLDB developers can understand when and where to use ExecutionContext and ExecutionContextRef objects. llvm-svn: 151009
2012-02-21 08:09:25 +08:00
if (first_frame_sp && process->ReadMemory (first_frame_sp, &frame.pc, sizeof(frame.pc), error) == sizeof(frame.pc))
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
cursor.fp = m_cursors.front().fp;
cursor.pc = frame.pc; // Set the new second frame PC
// Insert the second frame
m_cursors.insert(m_cursors.begin()+1, cursor);
m_cursors.front().fp = first_frame_sp;
}
}
}
}
}
// uint32_t i=0;
// printf(" PC FP\n");
// printf(" ------------------ ------------------ \n");
// for (i=0; i<m_cursors.size(); ++i)
// {
// printf("[%3u] 0x%16.16llx 0x%16.16llx\n", i, m_cursors[i].pc, m_cursors[i].fp);
// }
return m_cursors.size();
}
size_t
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr objects for the backlink to the lldb_private::Process. The issues we were running into before was someone was holding onto a shared pointer to a lldb_private::Thread for too long, and the lldb_private::Process parent object would get destroyed and the lldb_private::Thread had a "Process &m_process" member which would just treat whatever memory that used to be a Process as a valid Process. This was mostly happening for lldb_private::StackFrame objects that had a member like "Thread &m_thread". So this completes the internal strong/weak changes. Documented the ExecutionContext and ExecutionContextRef classes so that our LLDB developers can understand when and where to use ExecutionContext and ExecutionContextRef objects. llvm-svn: 151009
2012-02-21 08:09:25 +08:00
UnwindMacOSXFrameBackchain::GetStackFrameData_x86_64 (const ExecutionContext &exe_ctx)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
m_cursors.clear();
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr objects for the backlink to the lldb_private::Process. The issues we were running into before was someone was holding onto a shared pointer to a lldb_private::Thread for too long, and the lldb_private::Process parent object would get destroyed and the lldb_private::Thread had a "Process &m_process" member which would just treat whatever memory that used to be a Process as a valid Process. This was mostly happening for lldb_private::StackFrame objects that had a member like "Thread &m_thread". So this completes the internal strong/weak changes. Documented the ExecutionContext and ExecutionContextRef classes so that our LLDB developers can understand when and where to use ExecutionContext and ExecutionContextRef objects. llvm-svn: 151009
2012-02-21 08:09:25 +08:00
Process *process = exe_ctx.GetProcessPtr();
if (process == NULL)
return 0;
StackFrame *first_frame = exe_ctx.GetFramePtr();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
std::pair<lldb::addr_t, lldb::addr_t> fp_pc_pair;
typedef fixups, patch from Jean-Daniel Dupas. llvm-svn: 107794
2010-07-08 01:07:17 +08:00
struct Frame_x86_64
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
uint64_t fp;
uint64_t pc;
};
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();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
assert (reg_ctx);
Cursor cursor;
cursor.pc = reg_ctx->GetPC (LLDB_INVALID_ADDRESS);
cursor.fp = reg_ctx->GetFP (0);
Frame_x86_64 frame = { cursor.fp, cursor.pc };
m_cursors.push_back(cursor);
Error error;
const size_t k_frame_size = sizeof(frame);
while (frame.fp != 0 && frame.pc != 0 && ((frame.fp & 7) == 0))
{
// Read both the FP and PC (16 bytes)
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr objects for the backlink to the lldb_private::Process. The issues we were running into before was someone was holding onto a shared pointer to a lldb_private::Thread for too long, and the lldb_private::Process parent object would get destroyed and the lldb_private::Thread had a "Process &m_process" member which would just treat whatever memory that used to be a Process as a valid Process. This was mostly happening for lldb_private::StackFrame objects that had a member like "Thread &m_thread". So this completes the internal strong/weak changes. Documented the ExecutionContext and ExecutionContextRef classes so that our LLDB developers can understand when and where to use ExecutionContext and ExecutionContextRef objects. llvm-svn: 151009
2012-02-21 08:09:25 +08:00
if (process->ReadMemory (frame.fp, &frame.fp, k_frame_size, error) != k_frame_size)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
break;
if (frame.pc >= 0x1000)
{
cursor.pc = frame.pc;
cursor.fp = frame.fp;
m_cursors.push_back (cursor);
}
}
if (!m_cursors.empty())
{
lldb::addr_t first_frame_pc = m_cursors.front().pc;
if (first_frame_pc != LLDB_INVALID_ADDRESS)
{
const uint32_t resolve_scope = eSymbolContextModule |
eSymbolContextCompUnit |
eSymbolContextFunction |
eSymbolContextSymbol;
SymbolContext first_frame_sc(first_frame->GetSymbolContext(resolve_scope));
const AddressRange *addr_range_ptr = NULL;
<rdar://problem/10997402> This fix really needed to happen as a previous fix I had submitted for calculating symbol sizes made many symbols appear to have zero size since the function that was calculating the symbol size was calling another function that would cause the calculation to happen again. This resulted in some symbols having zero size when they shouldn't. This could then cause infinite stack traces and many other side affects. llvm-svn: 152244
2012-03-08 05:03:09 +08:00
AddressRange range;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (first_frame_sc.function)
addr_range_ptr = &first_frame_sc.function->GetAddressRange();
else if (first_frame_sc.symbol)
<rdar://problem/10997402> This fix really needed to happen as a previous fix I had submitted for calculating symbol sizes made many symbols appear to have zero size since the function that was calculating the symbol size was calling another function that would cause the calculation to happen again. This resulted in some symbols having zero size when they shouldn't. This could then cause infinite stack traces and many other side affects. llvm-svn: 152244
2012-03-08 05:03:09 +08:00
{
range.GetBaseAddress() = first_frame_sc.symbol->GetAddress();
range.SetByteSize (first_frame_sc.symbol->GetByteSize());
addr_range_ptr = &range;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (addr_range_ptr)
{
Got a lot of the kinks worked out in the inline support after debugging more complex inlined examples. StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()". This is because inlined frames will have a PC value that is the same as the concrete frame that owns the inlined frame, yet the code locations for the frame can be different. We also need to be able to get the real PC value for a given frame so that variables evaluate correctly. To get the actual PC value for a frame you can use: addr_t pc = frame->GetRegisterContext()->GetPC(); Some issues with the StackFrame stomping on its own symbol context were resolved which were causing the information to change for a frame when the stack ID was calculated. Also the StackFrame will now correctly store the symbol context resolve flags for any extra bits of information that were looked up (if you ask for a block only and you find one, you will alwasy have the compile unit and function). llvm-svn: 111964
2010-08-25 05:05:24 +08:00
if (first_frame->GetFrameCodeAddress() == addr_range_ptr->GetBaseAddress())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
// We are at the first instruction, so we can recover the
// previous PC by dereferencing the SP
lldb::addr_t first_frame_sp = reg_ctx->GetSP (0);
// Read the real second frame return address into frame.pc
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr objects for the backlink to the lldb_private::Process. The issues we were running into before was someone was holding onto a shared pointer to a lldb_private::Thread for too long, and the lldb_private::Process parent object would get destroyed and the lldb_private::Thread had a "Process &m_process" member which would just treat whatever memory that used to be a Process as a valid Process. This was mostly happening for lldb_private::StackFrame objects that had a member like "Thread &m_thread". So this completes the internal strong/weak changes. Documented the ExecutionContext and ExecutionContextRef classes so that our LLDB developers can understand when and where to use ExecutionContext and ExecutionContextRef objects. llvm-svn: 151009
2012-02-21 08:09:25 +08:00
if (process->ReadMemory (first_frame_sp, &frame.pc, sizeof(frame.pc), error) == sizeof(frame.pc))
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
cursor.fp = m_cursors.front().fp;
cursor.pc = frame.pc; // Set the new second frame PC
// Insert the second frame
m_cursors.insert(m_cursors.begin()+1, cursor);
m_cursors.front().fp = first_frame_sp;
}
}
}
}
}
return m_cursors.size();
}