replica
/
hanchenye-llvm-project
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
hanchenye-llvm-project/lldb/source/lldb.cpp

225 lines
7.4 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
//===-- 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"
Make include paths work on Linux. ifdef out stuff that isn't relevant to Linux or doesn't compile on Linux. llvm-svn: 105923
2010-06-14 03:36:42 +08:00
#include "lldb/Core/ArchSpec.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Core/Log.h"
Modified the PluginManager to be ready for loading plug-ins from a system LLDB plugin directory and a user LLDB plugin directory. We currently still need to work out at what layer the plug-ins will be, but at least we are prepared for plug-ins. Plug-ins will attempt to be loaded from the "/Developer/Library/PrivateFrameworks/LLDB.framework/Resources/Plugins" folder, and from the "~/Library/Application Support/LLDB/Plugins" folder on MacOSX. Each plugin will be scanned for: extern "C" bool LLDBPluginInitialize(void); extern "C" void LLDBPluginTerminate(void); If at least LLDBPluginInitialize is found, the plug-in will be loaded. The LLDBPluginInitialize function returns a bool that indicates if the plug-in should stay loaded or not (plug-ins might check the current OS, current hardware, or anything else and determine they don't want to run on the current host). The plug-in is uniqued by path and added to a static loaded plug-in map. The plug-in scanning happens during "lldb_private::Initialize()" which calls to the PluginManager::Initialize() function. Likewise with termination lldb_private::Terminate() calls PluginManager::Terminate(). The paths for the plug-in directories is fetched through new Host calls: bool Host::GetLLDBPath (ePathTypeLLDBSystemPlugins, dir_spec); bool Host::GetLLDBPath (ePathTypeLLDBUserPlugins, dir_spec); This way linux and other systems can define their own appropriate locations for plug-ins to be loaded. To allow dynamic shared library loading, the Host layer has also been modified to include shared library open, close and get symbol: static void * Host::DynamicLibraryOpen (const FileSpec &file_spec, Error &error); static Error Host::DynamicLibraryClose (void *dynamic_library_handle); static void * Host::DynamicLibraryGetSymbol (void *dynamic_library_handle, const char *symbol_name, Error &error); lldb_private::FileSpec also has been modified to support directory enumeration in an attempt to abstract the directory enumeration into one spot in the code. The directory enumertion function is static and takes a callback: typedef enum EnumerateDirectoryResult { eEnumerateDirectoryResultNext, // Enumerate next entry in the current directory eEnumerateDirectoryResultEnter, // Recurse into the current entry if it is a directory or symlink, or next if not eEnumerateDirectoryResultExit, // Exit from the current directory at the current level. eEnumerateDirectoryResultQuit // Stop directory enumerations at any level }; typedef FileSpec::EnumerateDirectoryResult (*EnumerateDirectoryCallbackType) (void *baton, FileSpec::FileType file_type, const FileSpec &spec); static FileSpec::EnumerateDirectoryResult FileSpec::EnumerateDirectory (const char *dir_path, bool find_directories, bool find_files, bool find_other, EnumerateDirectoryCallbackType callback, void *callback_baton); This allow clients to specify the directory to search, and specifies if only files, directories or other (pipe, symlink, fifo, etc) files will cause the callback to be called. The callback also gets to return with the action that should be performed after this directory entry. eEnumerateDirectoryResultNext specifies to continue enumerating through a directory with the next entry. eEnumerateDirectoryResultEnter specifies to recurse down into a directory entry, or if the file is not a directory or symlink/alias to a directory, then just iterate to the next entry. eEnumerateDirectoryResultExit specifies to exit the current directory and skip any entries that might be remaining, yet continue enumerating to the next entry in the parent directory. And finally eEnumerateDirectoryResultQuit means to abort all directory enumerations at all levels. Modified the Declaration class to not include column information currently since we don't have any compilers that currently support column based declaration information. Columns support can be re-enabled with the additions of a #define. Added the ability to find an EmulateInstruction plug-in given a target triple and optional plug-in name in the plug-in manager. Fixed a few cases where opendir/readdir was being used, but yet not closedir was being used. Soon these will be deprecated in favor of the new directory enumeration call that was added to the FileSpec class. llvm-svn: 124716
2011-02-02 10:24:04 +08:00
#include "lldb/Core/PluginManager.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Core/Timer.h"
#include "lldb/Host/Host.h"
Make include paths work on Linux. ifdef out stuff that isn't relevant to Linux or doesn't compile on Linux. llvm-svn: 105923
2010-06-14 03:36:42 +08:00
#include "lldb/Host/Mutex.h"
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 08:29:16 +08:00
#include "lldb/Interpreter/ScriptInterpreter.h"
Fixes for linux building from Stephen Wilson. llvm-svn: 122002
2010-12-17 05:36:30 +08:00
#include "lldb/Target/Target.h"
#include "lldb/Target/Thread.h"
Make include paths work on Linux. ifdef out stuff that isn't relevant to Linux or doesn't compile on Linux. llvm-svn: 105923
2010-06-14 03:36:42 +08:00
#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"
Add a new ArchVolatileRegs plugin class to identify whether a given register number is treated as volatile or not for a given architecture/platform. approx 450 lines of boilerplate, 50 lines of actual code. :) llvm-svn: 114537
2010-09-22 15:37:07 +08:00
#include "Plugins/Process/Utility/ArchVolatileRegs-x86.h"
Add a new Process plugin for Linux. This component is still at an early stage, but allows for simple breakpoint/step-over operations and basic process control. The makefiles are set up to build the plugin under Linux only. llvm-svn: 109318
2010-07-24 10:19:04 +08:00
Make include paths work on Linux. ifdef out stuff that isn't relevant to Linux or doesn't compile on Linux. llvm-svn: 105923
2010-06-14 03:36:42 +08:00
#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"
Committing the skeleton of Language runtime plugin classes. llvm-svn: 114620
2010-09-23 10:01:19 +08:00
#include "Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.h"
Add a ObjC V1 runtime, and a generic AppleObjCRuntime plugin. Also move the Checker creation into the Apple Runtime code. llvm-svn: 118255
2010-11-05 02:30:59 +08:00
#include "Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV1.h"
#include "Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.h"
Make include paths work on Linux. ifdef out stuff that isn't relevant to Linux or doesn't compile on Linux. llvm-svn: 105923
2010-06-14 03:36:42 +08:00
#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
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Add a new Process plugin for Linux. This component is still at an early stage, but allows for simple breakpoint/step-over operations and basic process control. The makefiles are set up to build the plugin under Linux only. llvm-svn: 109318
2010-07-24 10:19:04 +08:00
#ifdef __linux__
#include "Plugins/Process/Linux/ProcessLinux.h"
Initial support for a DynamicLoader plugin on Linux. This patch is enough to have shared objects recognized by LLDB. We can handle position independent executables. We can handle dynamically loaded modules brought in via dlopen. The DYLDRendezvous class provides an interface to a structure present in the address space of ELF-based processes. This structure provides the address of a function which is called by the linker each time a shared object is loaded and unloaded (thus a breakpoint at that address will let LLDB intercept such events), a list of entries describing the currently loaded shared objects, plus a few other things. On Linux, processes are brought up with an auxiliary vector on the stack. One element in this vector contains the (possibly dynamic) entry address of the process. One does not need to walk the stack to find this information as it is also available under /proc/<pid>/auxv. The new AuxVector class provides a convenient read-only view of this auxiliary vector information. We use the dynamic entry address and the address as specified in the object file to compute the actual load address of the inferior image. This strategy works for both normal executables and PIE's. llvm-svn: 123592
2011-01-17 03:45:39 +08:00
#include "Plugins/DynamicLoader/Linux-DYLD/DynamicLoaderLinuxDYLD.h"
Add a new Process plugin for Linux. This component is still at an early stage, but allows for simple breakpoint/step-over operations and basic process control. The makefiles are set up to build the plugin under Linux only. llvm-svn: 109318
2010-07-24 10:19:04 +08:00
#endif
Fixes for linux building from Stephen Wilson. llvm-svn: 122001
2010-12-17 05:33:41 +08:00
using namespace lldb;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
using namespace lldb_private;
void
lldb_private::Initialize ()
{
// Make sure we inialize only once
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 08:29:16 +08:00
static Mutex g_inited_mutex(Mutex::eMutexTypeRecursive);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
static bool g_inited = false;
Mutex::Locker locker(g_inited_mutex);
if (!g_inited)
{
g_inited = true;
Cleaned up code that wasn't using the Initialize and Terminate paradigm by changing it to use it. There was an extra parameter added to the static accessor global user settings controllers that wasn't needed. A bool was being used as a parameter to the accessor just so it could be used to clean up the global user settings controller which is now fixed by splitting up the initialization into the "static void Class::Initialize()", access into the "static UserSettingsControllerSP & Class::GetSettingsController()", and cleanup into "static void Class::Terminate()". Also added initialize and terminate calls to the logging code to avoid issues when LLDB is shutting down. There were cases after the logging was switched over to use shared pointers where we could crash if the global destructor chain was being run and it causes the log to be destroyed and any any logging occurred. llvm-svn: 119757
2010-11-19 07:32:35 +08:00
Log::Initialize();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Timer::Initialize ();
Timer scoped_timer (__PRETTY_FUNCTION__, __PRETTY_FUNCTION__);
Cleaned up code that wasn't using the Initialize and Terminate paradigm by changing it to use it. There was an extra parameter added to the static accessor global user settings controllers that wasn't needed. A bool was being used as a parameter to the accessor just so it could be used to clean up the global user settings controller which is now fixed by splitting up the initialization into the "static void Class::Initialize()", access into the "static UserSettingsControllerSP & Class::GetSettingsController()", and cleanup into "static void Class::Terminate()". Also added initialize and terminate calls to the logging code to avoid issues when LLDB is shutting down. There were cases after the logging was switched over to use shared pointers where we could crash if the global destructor chain was being run and it causes the log to be destroyed and any any logging occurred. llvm-svn: 119757
2010-11-19 07:32:35 +08:00
Target::Initialize ();
Process::Initialize ();
Thread::Initialize ();
Make include paths work on Linux. ifdef out stuff that isn't relevant to Linux or doesn't compile on Linux. llvm-svn: 105923
2010-06-14 03:36:42 +08:00
DisassemblerLLVM::Initialize();
ObjectContainerBSDArchive::Initialize();
ObjectFileELF::Initialize();
SymbolFileDWARF::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();
All UnwindPlan objects are now passed around as shared pointers. ArchDefaultUnwindPlan plug-in interfaces are now cached per architecture instead of being leaked for every frame. Split the ArchDefaultUnwindPlan_x86 into ArchDefaultUnwindPlan_x86_64 and ArchDefaultUnwindPlan_i386 interfaces. There were sporadic crashes that were due to something leaking or being destroyed when doing stack crawls. This patch should clear up these issues. llvm-svn: 125541
2011-02-15 08:19:15 +08:00
ArchDefaultUnwindPlan_x86_64::Initialize();
ArchDefaultUnwindPlan_i386::Initialize();
Add a new ArchVolatileRegs plugin class to identify whether a given register number is treated as volatile or not for a given architecture/platform. approx 450 lines of boilerplate, 50 lines of actual code. :) llvm-svn: 114537
2010-09-22 15:37:07 +08:00
ArchVolatileRegs_x86::Initialize();
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 08:29:16 +08:00
ScriptInterpreter::Initialize ();
Add a new Process plugin for Linux. This component is still at an early stage, but allows for simple breakpoint/step-over operations and basic process control. The makefiles are set up to build the plugin under Linux only. llvm-svn: 109318
2010-07-24 10:19:04 +08:00
Make include paths work on Linux. ifdef out stuff that isn't relevant to Linux or doesn't compile on Linux. llvm-svn: 105923
2010-06-14 03:36:42 +08:00
#ifdef __APPLE__
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
ABIMacOSX_i386::Initialize();
ABISysV_x86_64::Initialize();
DynamicLoaderMacOSXDYLD::Initialize();
Initialize SymbolFileDWARFDebugMap on Apple platforms only. SymbolFileDWARFDebugMap handles the parsing of OSO stabs which are effectively a Mach-O specific feature and is incompatible with other object file formats. llvm-svn: 123308
2011-01-12 12:22:09 +08:00
SymbolFileDWARFDebugMap::Initialize();
Committing the skeleton of Language runtime plugin classes. llvm-svn: 114620
2010-09-23 10:01:19 +08:00
ItaniumABILanguageRuntime::Initialize();
AppleObjCRuntimeV2::Initialize();
Add a ObjC V1 runtime, and a generic AppleObjCRuntime plugin. Also move the Checker creation into the Apple Runtime code. llvm-svn: 118255
2010-11-05 02:30:59 +08:00
AppleObjCRuntimeV1::Initialize();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
ObjectContainerUniversalMachO::Initialize();
ObjectFileMachO::Initialize();
ProcessGDBRemote::Initialize();
Disable "process.macosx" plugin, since it is not being actively supported at the moment, and no longer works properly (bit rot). llvm-svn: 116626
2010-10-16 05:52:38 +08:00
//ProcessMacOSX::Initialize();
Add a new Process plugin for Linux. This component is still at an early stage, but allows for simple breakpoint/step-over operations and basic process control. The makefiles are set up to build the plugin under Linux only. llvm-svn: 109318
2010-07-24 10:19:04 +08:00
SymbolVendorMacOSX::Initialize();
#endif
#ifdef __linux__
ProcessLinux::Initialize();
Initial support for a DynamicLoader plugin on Linux. This patch is enough to have shared objects recognized by LLDB. We can handle position independent executables. We can handle dynamically loaded modules brought in via dlopen. The DYLDRendezvous class provides an interface to a structure present in the address space of ELF-based processes. This structure provides the address of a function which is called by the linker each time a shared object is loaded and unloaded (thus a breakpoint at that address will let LLDB intercept such events), a list of entries describing the currently loaded shared objects, plus a few other things. On Linux, processes are brought up with an auxiliary vector on the stack. One element in this vector contains the (possibly dynamic) entry address of the process. One does not need to walk the stack to find this information as it is also available under /proc/<pid>/auxv. The new AuxVector class provides a convenient read-only view of this auxiliary vector information. We use the dynamic entry address and the address as specified in the object file to compute the actual load address of the inferior image. This strategy works for both normal executables and PIE's. llvm-svn: 123592
2011-01-17 03:45:39 +08:00
DynamicLoaderLinuxDYLD::Initialize();
Make include paths work on Linux. ifdef out stuff that isn't relevant to Linux or doesn't compile on Linux. llvm-svn: 105923
2010-06-14 03:36:42 +08:00
#endif
Modified the PluginManager to be ready for loading plug-ins from a system LLDB plugin directory and a user LLDB plugin directory. We currently still need to work out at what layer the plug-ins will be, but at least we are prepared for plug-ins. Plug-ins will attempt to be loaded from the "/Developer/Library/PrivateFrameworks/LLDB.framework/Resources/Plugins" folder, and from the "~/Library/Application Support/LLDB/Plugins" folder on MacOSX. Each plugin will be scanned for: extern "C" bool LLDBPluginInitialize(void); extern "C" void LLDBPluginTerminate(void); If at least LLDBPluginInitialize is found, the plug-in will be loaded. The LLDBPluginInitialize function returns a bool that indicates if the plug-in should stay loaded or not (plug-ins might check the current OS, current hardware, or anything else and determine they don't want to run on the current host). The plug-in is uniqued by path and added to a static loaded plug-in map. The plug-in scanning happens during "lldb_private::Initialize()" which calls to the PluginManager::Initialize() function. Likewise with termination lldb_private::Terminate() calls PluginManager::Terminate(). The paths for the plug-in directories is fetched through new Host calls: bool Host::GetLLDBPath (ePathTypeLLDBSystemPlugins, dir_spec); bool Host::GetLLDBPath (ePathTypeLLDBUserPlugins, dir_spec); This way linux and other systems can define their own appropriate locations for plug-ins to be loaded. To allow dynamic shared library loading, the Host layer has also been modified to include shared library open, close and get symbol: static void * Host::DynamicLibraryOpen (const FileSpec &file_spec, Error &error); static Error Host::DynamicLibraryClose (void *dynamic_library_handle); static void * Host::DynamicLibraryGetSymbol (void *dynamic_library_handle, const char *symbol_name, Error &error); lldb_private::FileSpec also has been modified to support directory enumeration in an attempt to abstract the directory enumeration into one spot in the code. The directory enumertion function is static and takes a callback: typedef enum EnumerateDirectoryResult { eEnumerateDirectoryResultNext, // Enumerate next entry in the current directory eEnumerateDirectoryResultEnter, // Recurse into the current entry if it is a directory or symlink, or next if not eEnumerateDirectoryResultExit, // Exit from the current directory at the current level. eEnumerateDirectoryResultQuit // Stop directory enumerations at any level }; typedef FileSpec::EnumerateDirectoryResult (*EnumerateDirectoryCallbackType) (void *baton, FileSpec::FileType file_type, const FileSpec &spec); static FileSpec::EnumerateDirectoryResult FileSpec::EnumerateDirectory (const char *dir_path, bool find_directories, bool find_files, bool find_other, EnumerateDirectoryCallbackType callback, void *callback_baton); This allow clients to specify the directory to search, and specifies if only files, directories or other (pipe, symlink, fifo, etc) files will cause the callback to be called. The callback also gets to return with the action that should be performed after this directory entry. eEnumerateDirectoryResultNext specifies to continue enumerating through a directory with the next entry. eEnumerateDirectoryResultEnter specifies to recurse down into a directory entry, or if the file is not a directory or symlink/alias to a directory, then just iterate to the next entry. eEnumerateDirectoryResultExit specifies to exit the current directory and skip any entries that might be remaining, yet continue enumerating to the next entry in the parent directory. And finally eEnumerateDirectoryResultQuit means to abort all directory enumerations at all levels. Modified the Declaration class to not include column information currently since we don't have any compilers that currently support column based declaration information. Columns support can be re-enabled with the additions of a #define. Added the ability to find an EmulateInstruction plug-in given a target triple and optional plug-in name in the plug-in manager. Fixed a few cases where opendir/readdir was being used, but yet not closedir was being used. Soon these will be deprecated in favor of the new directory enumeration call that was added to the FileSpec class. llvm-svn: 124716
2011-02-02 10:24:04 +08:00
// Scan for any system or user LLDB plug-ins
PluginManager::Initialize();
Added new target instance settings for execution settings: Targets can now specify some additional parameters for when we debug executables that can help with plug-in selection: target.execution-level = auto | user | kernel target.execution-mode = auto | dynamic | static target.execution-os-type = auto | none | halted | live On some systems, the binaries that are created are the same wether you use them to debug a kernel, or a user space program. Many times inspecting an object file can reveal what an executable should be. For these cases we can now be a little more complete by specifying wether to detect all of these things automatically (inspect the main executable file and select a plug-in accordingly), or manually to force the selection of certain plug-ins. To do this we now allow the specficifation of wether one is debugging a user space program (target.execution-level = user) or a kernel program (target.execution-level = kernel). We can also specify if we want to debug a program where shared libraries are dynamically loaded using a DynamicLoader plug-in (target.execution-mode = dynamic), or wether we will treat all symbol files as already linked at the correct address (target.execution-mode = static). We can also specify if the inferior we are debugging is being debugged on a bare board (target.execution-os-type = none), or debugging an OS where we have a JTAG or other direct connection to the inferior stops the entire OS (target.execution-os-type = halted), or if we are debugging a program on something that has live debug services (target.execution-os-type = live). For the "target.execution-os-type = halted" mode, we will need to create ProcessHelper plug-ins that allow us to extract the process/thread and other OS information by reading/writing memory. This should allow LLDB to be used for a wide variety of debugging tasks and handle them all correctly. llvm-svn: 125815
2011-02-18 09:44:25 +08:00
// The process needs to know about installed plug-ins
Process::DidInitialize ();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
void
lldb_private::WillTerminate()
{
Host::WillTerminate();
}
void
lldb_private::Terminate ()
{
Timer scoped_timer (__PRETTY_FUNCTION__, __PRETTY_FUNCTION__);
Modified the PluginManager to be ready for loading plug-ins from a system LLDB plugin directory and a user LLDB plugin directory. We currently still need to work out at what layer the plug-ins will be, but at least we are prepared for plug-ins. Plug-ins will attempt to be loaded from the "/Developer/Library/PrivateFrameworks/LLDB.framework/Resources/Plugins" folder, and from the "~/Library/Application Support/LLDB/Plugins" folder on MacOSX. Each plugin will be scanned for: extern "C" bool LLDBPluginInitialize(void); extern "C" void LLDBPluginTerminate(void); If at least LLDBPluginInitialize is found, the plug-in will be loaded. The LLDBPluginInitialize function returns a bool that indicates if the plug-in should stay loaded or not (plug-ins might check the current OS, current hardware, or anything else and determine they don't want to run on the current host). The plug-in is uniqued by path and added to a static loaded plug-in map. The plug-in scanning happens during "lldb_private::Initialize()" which calls to the PluginManager::Initialize() function. Likewise with termination lldb_private::Terminate() calls PluginManager::Terminate(). The paths for the plug-in directories is fetched through new Host calls: bool Host::GetLLDBPath (ePathTypeLLDBSystemPlugins, dir_spec); bool Host::GetLLDBPath (ePathTypeLLDBUserPlugins, dir_spec); This way linux and other systems can define their own appropriate locations for plug-ins to be loaded. To allow dynamic shared library loading, the Host layer has also been modified to include shared library open, close and get symbol: static void * Host::DynamicLibraryOpen (const FileSpec &file_spec, Error &error); static Error Host::DynamicLibraryClose (void *dynamic_library_handle); static void * Host::DynamicLibraryGetSymbol (void *dynamic_library_handle, const char *symbol_name, Error &error); lldb_private::FileSpec also has been modified to support directory enumeration in an attempt to abstract the directory enumeration into one spot in the code. The directory enumertion function is static and takes a callback: typedef enum EnumerateDirectoryResult { eEnumerateDirectoryResultNext, // Enumerate next entry in the current directory eEnumerateDirectoryResultEnter, // Recurse into the current entry if it is a directory or symlink, or next if not eEnumerateDirectoryResultExit, // Exit from the current directory at the current level. eEnumerateDirectoryResultQuit // Stop directory enumerations at any level }; typedef FileSpec::EnumerateDirectoryResult (*EnumerateDirectoryCallbackType) (void *baton, FileSpec::FileType file_type, const FileSpec &spec); static FileSpec::EnumerateDirectoryResult FileSpec::EnumerateDirectory (const char *dir_path, bool find_directories, bool find_files, bool find_other, EnumerateDirectoryCallbackType callback, void *callback_baton); This allow clients to specify the directory to search, and specifies if only files, directories or other (pipe, symlink, fifo, etc) files will cause the callback to be called. The callback also gets to return with the action that should be performed after this directory entry. eEnumerateDirectoryResultNext specifies to continue enumerating through a directory with the next entry. eEnumerateDirectoryResultEnter specifies to recurse down into a directory entry, or if the file is not a directory or symlink/alias to a directory, then just iterate to the next entry. eEnumerateDirectoryResultExit specifies to exit the current directory and skip any entries that might be remaining, yet continue enumerating to the next entry in the parent directory. And finally eEnumerateDirectoryResultQuit means to abort all directory enumerations at all levels. Modified the Declaration class to not include column information currently since we don't have any compilers that currently support column based declaration information. Columns support can be re-enabled with the additions of a #define. Added the ability to find an EmulateInstruction plug-in given a target triple and optional plug-in name in the plug-in manager. Fixed a few cases where opendir/readdir was being used, but yet not closedir was being used. Soon these will be deprecated in favor of the new directory enumeration call that was added to the FileSpec class. llvm-svn: 124716
2011-02-02 10:24:04 +08:00
// Terminate and unload and loaded system or user LLDB plug-ins
PluginManager::Terminate();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
DisassemblerLLVM::Terminate();
ObjectContainerBSDArchive::Terminate();
ObjectFileELF::Terminate();
SymbolFileDWARF::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();
All UnwindPlan objects are now passed around as shared pointers. ArchDefaultUnwindPlan plug-in interfaces are now cached per architecture instead of being leaked for every frame. Split the ArchDefaultUnwindPlan_x86 into ArchDefaultUnwindPlan_x86_64 and ArchDefaultUnwindPlan_i386 interfaces. There were sporadic crashes that were due to something leaking or being destroyed when doing stack crawls. This patch should clear up these issues. llvm-svn: 125541
2011-02-15 08:19:15 +08:00
ArchDefaultUnwindPlan_i386::Terminate();
ArchDefaultUnwindPlan_x86_64::Terminate();
Add a new ArchVolatileRegs plugin class to identify whether a given register number is treated as volatile or not for a given architecture/platform. approx 450 lines of boilerplate, 50 lines of actual code. :) llvm-svn: 114537
2010-09-22 15:37:07 +08:00
ArchVolatileRegs_x86::Terminate();
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 08:29:16 +08:00
ScriptInterpreter::Terminate ();
Add a new Process plugin for Linux. This component is still at an early stage, but allows for simple breakpoint/step-over operations and basic process control. The makefiles are set up to build the plugin under Linux only. llvm-svn: 109318
2010-07-24 10:19:04 +08:00
Make include paths work on Linux. ifdef out stuff that isn't relevant to Linux or doesn't compile on Linux. llvm-svn: 105923
2010-06-14 03:36:42 +08:00
#ifdef __APPLE__
DynamicLoaderMacOSXDYLD::Terminate();
Initialize SymbolFileDWARFDebugMap on Apple platforms only. SymbolFileDWARFDebugMap handles the parsing of OSO stabs which are effectively a Mach-O specific feature and is incompatible with other object file formats. llvm-svn: 123308
2011-01-12 12:22:09 +08:00
SymbolFileDWARFDebugMap::Terminate();
Add a ObjC V1 runtime, and a generic AppleObjCRuntime plugin. Also move the Checker creation into the Apple Runtime code. llvm-svn: 118255
2010-11-05 02:30:59 +08:00
ItaniumABILanguageRuntime::Terminate();
AppleObjCRuntimeV2::Terminate();
AppleObjCRuntimeV1::Terminate();
Make include paths work on Linux. ifdef out stuff that isn't relevant to Linux or doesn't compile on Linux. llvm-svn: 105923
2010-06-14 03:36:42 +08:00
ObjectContainerUniversalMachO::Terminate();
ObjectFileMachO::Terminate();
ProcessGDBRemote::Terminate();
Disable "process.macosx" plugin, since it is not being actively supported at the moment, and no longer works properly (bit rot). llvm-svn: 116626
2010-10-16 05:52:38 +08:00
//ProcessMacOSX::Terminate();
Add a new Process plugin for Linux. This component is still at an early stage, but allows for simple breakpoint/step-over operations and basic process control. The makefiles are set up to build the plugin under Linux only. llvm-svn: 109318
2010-07-24 10:19:04 +08:00
SymbolVendorMacOSX::Terminate();
#endif
Cleaned up code that wasn't using the Initialize and Terminate paradigm by changing it to use it. There was an extra parameter added to the static accessor global user settings controllers that wasn't needed. A bool was being used as a parameter to the accessor just so it could be used to clean up the global user settings controller which is now fixed by splitting up the initialization into the "static void Class::Initialize()", access into the "static UserSettingsControllerSP & Class::GetSettingsController()", and cleanup into "static void Class::Terminate()". Also added initialize and terminate calls to the logging code to avoid issues when LLDB is shutting down. There were cases after the logging was switched over to use shared pointers where we could crash if the global destructor chain was being run and it causes the log to be destroyed and any any logging occurred. llvm-svn: 119757
2010-11-19 07:32:35 +08:00
Thread::Terminate ();
Process::Terminate ();
Target::Terminate ();
Add a new Process plugin for Linux. This component is still at an early stage, but allows for simple breakpoint/step-over operations and basic process control. The makefiles are set up to build the plugin under Linux only. llvm-svn: 109318
2010-07-24 10:19:04 +08:00
#ifdef __linux__
ProcessLinux::Terminate();
Initial support for a DynamicLoader plugin on Linux. This patch is enough to have shared objects recognized by LLDB. We can handle position independent executables. We can handle dynamically loaded modules brought in via dlopen. The DYLDRendezvous class provides an interface to a structure present in the address space of ELF-based processes. This structure provides the address of a function which is called by the linker each time a shared object is loaded and unloaded (thus a breakpoint at that address will let LLDB intercept such events), a list of entries describing the currently loaded shared objects, plus a few other things. On Linux, processes are brought up with an auxiliary vector on the stack. One element in this vector contains the (possibly dynamic) entry address of the process. One does not need to walk the stack to find this information as it is also available under /proc/<pid>/auxv. The new AuxVector class provides a convenient read-only view of this auxiliary vector information. We use the dynamic entry address and the address as specified in the object file to compute the actual load address of the inferior image. This strategy works for both normal executables and PIE's. llvm-svn: 123592
2011-01-17 03:45:39 +08:00
DynamicLoaderLinuxDYLD::Terminate();
Make include paths work on Linux. ifdef out stuff that isn't relevant to Linux or doesn't compile on Linux. llvm-svn: 105923
2010-06-14 03:36:42 +08:00
#endif
Cleaned up code that wasn't using the Initialize and Terminate paradigm by changing it to use it. There was an extra parameter added to the static accessor global user settings controllers that wasn't needed. A bool was being used as a parameter to the accessor just so it could be used to clean up the global user settings controller which is now fixed by splitting up the initialization into the "static void Class::Initialize()", access into the "static UserSettingsControllerSP & Class::GetSettingsController()", and cleanup into "static void Class::Terminate()". Also added initialize and terminate calls to the logging code to avoid issues when LLDB is shutting down. There were cases after the logging was switched over to use shared pointers where we could crash if the global destructor chain was being run and it causes the log to be destroyed and any any logging occurred. llvm-svn: 119757
2010-11-19 07:32:35 +08:00
Log::Terminate();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Declare LLDBVersionNumber extern "C" to make sure clang++ mangles it properly. Patch from Jean-Daniel Dupas! llvm-svn: 107765
2010-07-07 17:33:41 +08:00
extern "C" const double LLDBVersionNumber;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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;
}
Fixed the StackFrame to correctly resolve the StackID's SymbolContextScope. Added extra logging for stepping. Fixed an issue where cached stack frame data could be lost between runs when the thread plans read a stack frame. llvm-svn: 112973
2010-09-04 01:10:42 +08:00
const char *
lldb_private::GetVoteAsCString (lldb::Vote vote)
{
Cleaned up step logging a bit. llvm-svn: 113023
2010-09-04 06:45:01 +08:00
switch (vote)
{
case eVoteNo: return "no";
case eVoteNoOpinion: return "no opinion";
case eVoteYes: return "yes";
default:
break;
}
Fixed the StackFrame to correctly resolve the StackID's SymbolContextScope. Added extra logging for stepping. Fixed an issue where cached stack frame data could be lost between runs when the thread plans read a stack frame. llvm-svn: 112973
2010-09-04 01:10:42 +08:00
return "invalid";
}
Hooked up ability to look up data symbols so they show up in disassembly if the address comes from a data section. Fixed an issue that could occur when looking up a symbol that has a zero byte size where no match would be returned even if there was an exact symbol match. Cleaned up the section dump output and added the section type into the output. llvm-svn: 116017
2010-10-08 08:21:05 +08:00
const char *
lldb_private::GetSectionTypeAsCString (lldb::SectionType sect_type)
{
switch (sect_type)
{
case eSectionTypeInvalid: return "invalid";
case eSectionTypeCode: return "code";
case eSectionTypeContainer: return "container";
case eSectionTypeData: return "data";
case eSectionTypeDataCString: return "data-cstr";
case eSectionTypeDataCStringPointers: return "data-cstr-ptr";
case eSectionTypeDataSymbolAddress: return "data-symbol-addr";
case eSectionTypeData4: return "data-4-byte";
case eSectionTypeData8: return "data-8-byte";
case eSectionTypeData16: return "data-16-byte";
case eSectionTypeDataPointers: return "data-ptrs";
case eSectionTypeDebug: return "debug";
case eSectionTypeZeroFill: return "zero-fill";
case eSectionTypeDataObjCMessageRefs: return "objc-message-refs";
case eSectionTypeDataObjCCFStrings: return "objc-cfstrings";
case eSectionTypeDWARFDebugAbbrev: return "dwarf-abbrev";
case eSectionTypeDWARFDebugAranges: return "dwarf-aranges";
case eSectionTypeDWARFDebugFrame: return "dwarf-frame";
case eSectionTypeDWARFDebugInfo: return "dwarf-info";
case eSectionTypeDWARFDebugLine: return "dwarf-line";
case eSectionTypeDWARFDebugLoc: return "dwarf-loc";
case eSectionTypeDWARFDebugMacInfo: return "dwarf-macinfo";
case eSectionTypeDWARFDebugPubNames: return "dwarf-pubnames";
case eSectionTypeDWARFDebugPubTypes: return "dwarf-pubtypes";
case eSectionTypeDWARFDebugRanges: return "dwarf-ranges";
case eSectionTypeDWARFDebugStr: return "dwarf-str";
case eSectionTypeEHFrame: return "eh-frame";
case eSectionTypeOther: return "regular";
}
return "unknown";
}