flags such that symbols can be searched for within a shared library if desired.
Platforms that support the RTLD_FIRST flag can still take advantage of their
quicker lookups, and other platforms can still get the same fucntionality
with a little extra work.
Also changed LLDB_CONFIG flags over to either being defined, or not being
defined to stay in line with current open source practices and to prepare for
using autoconf or cmake to configure LLDB builds.
llvm-svn: 125064
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
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
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
Greg Clayton