hanchenye-llvm-project/lldb/source/lldb.cpp

154 lines
4.5 KiB
C++
Raw Normal View History

//===-- lldb.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-private.h"
#include "lldb/lldb-private-log.h"
#include "lldb/Core/ArchSpec.h"
#include "lldb/Core/Log.h"
#include "lldb/Core/Timer.h"
#include "lldb/Host/Host.h"
#include "lldb/Host/Mutex.h"
#include "Plugins/Disassembler/llvm/DisassemblerLLVM.h"
#include "Plugins/SymbolVendor/MacOSX/SymbolVendorMacOSX.h"
#include "Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.h"
#include "Plugins/ObjectFile/ELF/ObjectFileELF.h"
#include "Plugins/SymbolFile/DWARF/SymbolFileDWARF.h"
#include "Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h"
#include "Plugins/SymbolFile/Symtab/SymbolFileSymtab.h"
The first part of an lldb native stack unwinder. The Unwind and RegisterContext subclasses still need to be finished; none of this code is used by lldb at this point (unless you call into it by hand). The ObjectFile class now has an UnwindTable object. The UnwindTable object has a series of FuncUnwinders objects (Function Unwinders) -- one for each function in that ObjectFile we've backtraced through during this debug session. The FuncUnwinders object has a few different UnwindPlans. UnwindPlans are a generic way of describing how to find the canonical address of a given function's stack frame (the CFA idea from DWARF/eh_frame) and how to restore the caller frame's register values, if they have been saved by this function. UnwindPlans are created from different sources. One source is the eh_frame exception handling information generated by the compiler for unwinding an exception throw. Another source is an assembly language inspection class (UnwindAssemblyProfiler, uses the Plugin architecture) which looks at the instructions in the funciton prologue and describes the stack movements/register saves that are done. Two additional types of UnwindPlans that are worth noting are the "fast" stack UnwindPlan which is useful for making a first pass over a thread's stack, determining how many stack frames there are and retrieving the pc and CFA values for each frame (enough to create StackFrameIDs). Only a minimal set of registers is recovered during a fast stack walk. The final UnwindPlan is an architectural default unwind plan. These are provided by the ArchDefaultUnwindPlan class (which uses the plugin architecture). When no symbol/function address range can be found for a given pc value -- when we have no eh_frame information and when we don't have a start address so we can't examine the assembly language instrucitons -- we have to make a best guess about how to unwind. That's when we use the architectural default UnwindPlan. On x86_64, this would be to assume that rbp is used as a stack pointer and we can use that to find the caller's frame pointer and pc value. It's a last-ditch best guess about how to unwind out of a frame. There are heuristics about when to use one UnwindPlan versues the other -- this will all happen in the still-begin-written UnwindLLDB subclass of Unwind which runs the UnwindPlans. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
#include "Plugins/Process/Utility/UnwindAssemblyProfiler-x86.h"
#include "Plugins/Process/Utility/ArchDefaultUnwindPlan-x86.h"
#ifdef __APPLE__
#include "Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.h"
#include "Plugins/ABI/SysV-x86_64/ABISysV_x86_64.h"
#include "Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOSXDYLD.h"
#include "Plugins/ObjectContainer/Universal-Mach-O/ObjectContainerUniversalMachO.h"
#include "Plugins/ObjectFile/Mach-O/ObjectFileMachO.h"
#include "Plugins/Process/MacOSX-User/source/ProcessMacOSX.h"
#include "Plugins/Process/gdb-remote/ProcessGDBRemote.h"
#endif
#ifdef __linux__
#include "Plugins/Process/Linux/ProcessLinux.h"
#endif
using namespace lldb_private;
void
lldb_private::Initialize ()
{
// Make sure we inialize only once
static Mutex g_inited_mutex(Mutex::eMutexTypeNormal);
static bool g_inited = false;
Mutex::Locker locker(g_inited_mutex);
if (!g_inited)
{
g_inited = true;
Timer::Initialize ();
Timer scoped_timer (__PRETTY_FUNCTION__, __PRETTY_FUNCTION__);
Log::Callbacks log_callbacks = { DisableLog, EnableLog, ListLogCategories };
Log::RegisterLogChannel ("lldb", log_callbacks);
DisassemblerLLVM::Initialize();
ObjectContainerBSDArchive::Initialize();
ObjectFileELF::Initialize();
SymbolFileDWARF::Initialize();
SymbolFileDWARFDebugMap::Initialize();
SymbolFileSymtab::Initialize();
The first part of an lldb native stack unwinder. The Unwind and RegisterContext subclasses still need to be finished; none of this code is used by lldb at this point (unless you call into it by hand). The ObjectFile class now has an UnwindTable object. The UnwindTable object has a series of FuncUnwinders objects (Function Unwinders) -- one for each function in that ObjectFile we've backtraced through during this debug session. The FuncUnwinders object has a few different UnwindPlans. UnwindPlans are a generic way of describing how to find the canonical address of a given function's stack frame (the CFA idea from DWARF/eh_frame) and how to restore the caller frame's register values, if they have been saved by this function. UnwindPlans are created from different sources. One source is the eh_frame exception handling information generated by the compiler for unwinding an exception throw. Another source is an assembly language inspection class (UnwindAssemblyProfiler, uses the Plugin architecture) which looks at the instructions in the funciton prologue and describes the stack movements/register saves that are done. Two additional types of UnwindPlans that are worth noting are the "fast" stack UnwindPlan which is useful for making a first pass over a thread's stack, determining how many stack frames there are and retrieving the pc and CFA values for each frame (enough to create StackFrameIDs). Only a minimal set of registers is recovered during a fast stack walk. The final UnwindPlan is an architectural default unwind plan. These are provided by the ArchDefaultUnwindPlan class (which uses the plugin architecture). When no symbol/function address range can be found for a given pc value -- when we have no eh_frame information and when we don't have a start address so we can't examine the assembly language instrucitons -- we have to make a best guess about how to unwind. That's when we use the architectural default UnwindPlan. On x86_64, this would be to assume that rbp is used as a stack pointer and we can use that to find the caller's frame pointer and pc value. It's a last-ditch best guess about how to unwind out of a frame. There are heuristics about when to use one UnwindPlan versues the other -- this will all happen in the still-begin-written UnwindLLDB subclass of Unwind which runs the UnwindPlans. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
UnwindAssemblyProfiler_x86::Initialize();
ArchDefaultUnwindPlan_x86::Initialize();
#ifdef __APPLE__
ABIMacOSX_i386::Initialize();
ABISysV_x86_64::Initialize();
DynamicLoaderMacOSXDYLD::Initialize();
ObjectContainerUniversalMachO::Initialize();
ObjectFileMachO::Initialize();
ProcessGDBRemote::Initialize();
ProcessMacOSX::Initialize();
SymbolVendorMacOSX::Initialize();
#endif
Debugger::GetSettingsController (false);
Target::GetSettingsController (false);
Process::GetSettingsController (false);
Thread::GetSettingsController (false);
#ifdef __linux__
ProcessLinux::Initialize();
#endif
}
}
void
lldb_private::WillTerminate()
{
Host::WillTerminate();
}
void
lldb_private::Terminate ()
{
Timer scoped_timer (__PRETTY_FUNCTION__, __PRETTY_FUNCTION__);
DisassemblerLLVM::Terminate();
ObjectContainerBSDArchive::Terminate();
ObjectFileELF::Terminate();
SymbolFileDWARF::Terminate();
SymbolFileDWARFDebugMap::Terminate();
SymbolFileSymtab::Terminate();
The first part of an lldb native stack unwinder. The Unwind and RegisterContext subclasses still need to be finished; none of this code is used by lldb at this point (unless you call into it by hand). The ObjectFile class now has an UnwindTable object. The UnwindTable object has a series of FuncUnwinders objects (Function Unwinders) -- one for each function in that ObjectFile we've backtraced through during this debug session. The FuncUnwinders object has a few different UnwindPlans. UnwindPlans are a generic way of describing how to find the canonical address of a given function's stack frame (the CFA idea from DWARF/eh_frame) and how to restore the caller frame's register values, if they have been saved by this function. UnwindPlans are created from different sources. One source is the eh_frame exception handling information generated by the compiler for unwinding an exception throw. Another source is an assembly language inspection class (UnwindAssemblyProfiler, uses the Plugin architecture) which looks at the instructions in the funciton prologue and describes the stack movements/register saves that are done. Two additional types of UnwindPlans that are worth noting are the "fast" stack UnwindPlan which is useful for making a first pass over a thread's stack, determining how many stack frames there are and retrieving the pc and CFA values for each frame (enough to create StackFrameIDs). Only a minimal set of registers is recovered during a fast stack walk. The final UnwindPlan is an architectural default unwind plan. These are provided by the ArchDefaultUnwindPlan class (which uses the plugin architecture). When no symbol/function address range can be found for a given pc value -- when we have no eh_frame information and when we don't have a start address so we can't examine the assembly language instrucitons -- we have to make a best guess about how to unwind. That's when we use the architectural default UnwindPlan. On x86_64, this would be to assume that rbp is used as a stack pointer and we can use that to find the caller's frame pointer and pc value. It's a last-ditch best guess about how to unwind out of a frame. There are heuristics about when to use one UnwindPlan versues the other -- this will all happen in the still-begin-written UnwindLLDB subclass of Unwind which runs the UnwindPlans. llvm-svn: 113581
2010-09-10 15:49:16 +08:00
UnwindAssemblyProfiler_x86::Terminate();
ArchDefaultUnwindPlan_x86::Terminate();
#ifdef __APPLE__
DynamicLoaderMacOSXDYLD::Terminate();
ObjectContainerUniversalMachO::Terminate();
ObjectFileMachO::Terminate();
ProcessGDBRemote::Terminate();
ProcessMacOSX::Terminate();
SymbolVendorMacOSX::Terminate();
#endif
Thread::GetSettingsController (true);
Process::GetSettingsController (true);
Target::GetSettingsController (true);
Debugger::GetSettingsController (true);
#ifdef __linux__
ProcessLinux::Terminate();
#endif
}
extern "C" const double LLDBVersionNumber;
const char *
lldb_private::GetVersion ()
{
static char g_version_string[32];
if (g_version_string[0] == '\0')
::snprintf (g_version_string, sizeof(g_version_string), "LLDB-%g", LLDBVersionNumber);
return g_version_string;
}
const char *
lldb_private::GetVoteAsCString (lldb::Vote vote)
{
switch (vote)
{
case eVoteNo: return "no";
case eVoteNoOpinion: return "no opinion";
case eVoteYes: return "yes";
default:
break;
}
return "invalid";
}