History log of /external/lldb/source/Host/macosx/Symbols.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
42b336cd509cad89be08f78775d3b1c8c7656a1b 04-May-2013 Jason Molenda <jmolenda@apple.com> Remove the UUID::GetAsCString() method which required a buffer to save the
UUID string in; added UUID::GetAsString() which returns the uuid string in
a std::string. Updated callers to use the new method.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@181078 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
50972aead4df9c8524d5f8b522e9d92895c72e48 09-Feb-2013 Sean Callanan <scallanan@apple.com> Fixed a crash when we didn't get a plist but tried
to pass it to CFGetTypeID() anyway.

<rdar://problem/13181904>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@174772 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
2ddb2b8aed6d43665c6955255f6a077574a08412 01-Feb-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13092722>

Fix in loading mach files from memory when using DynamicLoaderMacOSXDYLD.

Removed the uuid mismatch warning that could be spit out and any time during debugging and removed the test case that was looking for that. Currently the "add-dsym" or "target symbols add" command will report an error when the UUID's don't match.

Be more careful when checking and resolving section + offset addresses to make sure none of the base addresses are invalid.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@174222 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
36da2aa6dc5ad9994b638ed09eb81c44cc05540b 25-Jan-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13069948>

Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.

So I defined a new "lldb::offset_t" which should be used for all file offsets.

After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.

Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@173463 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
64246cda58b64208f5c415fc52909c45c3dc3e2b 21-Dec-2012 Sean Callanan <scallanan@apple.com> Fixed a bug where we could accept the wrong
slice of a fat dSYM in certain cases.

<rdar://problem/12921206>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@170926 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
878f13c99c0dcbe2a5ac22f233522233d8dc52d4 15-Dec-2012 Sean Callanan <scallanan@apple.com> Fixed two conditionals that I accidentally
reversed in r170152.

<rdar://problem/12886584>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@170256 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
40e278caddf5442776f9408f20d757cc85fe630a 13-Dec-2012 Sean Callanan <scallanan@apple.com> Removed the == and != operators from ArchSpec, since
equality can be strict or loose and we want code to
explicitly choose one or the other.

Also renamed the Compare function to IsEqualTo, to
avoid confusion.

<rdar://problem/12856749>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@170152 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
f25697550690a7cda6a013c596fb8e6159b58256 30-Oct-2012 Jason Molenda <jmolenda@apple.com> Change the MacOSX Symbols::DownloadObjectAndSymbolFile to look up
"~rc" via getpwnam() instead of doing tilde expansion and doing soft-link
dereferencing via realpath() - if we're pointing to a softlink, leave it
as-is.
<rdar://problem/12597698>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@167052 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
d6d45ceeae51b6dbb9221a3cf82441afa212a7dc 09-Oct-2012 Jason Molenda <jmolenda@apple.com> Add a parameter to Symbols::DownloadObjectAndSymbolFile() to control
whether we try to call an external program to load symbols unconditionally,
or if we check the user's preferences before calling it.

ProcessMachCore now sets CanJIT to false - we can't execute code in a core file.

DynamicLoaderDarwinKernel::OSKextLoadedKextSummary::LoadImageUsingMemoryModule changed
to load the kernel from an on-disk file if at all possible.
Don't load the kext binaries out of memory from the remote systems - their linkedit doesn't
seem to be in a good state and we'll error out down in SymbolVendorMacOSX if we try to use
the in-memory images.
Call Symbols::DownloadObjectAndSymbolFile to get the kext/kernel binary -- the external
program may be able to give us a file path on the local filesystem instead of reading
the binary / dSYM over a network drive every time. Fall back to calling
Target::GetSharedModule() like before if DownloadObjectAndSymbolFile fails.




git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@165471 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
1b09dfef975addaa4aa330edb1dc7e28b8436028 05-Oct-2012 Jason Molenda <jmolenda@apple.com> Symbols::LocateMacOSXFilesUsingDebugSymbols() - perform tilde
expansion on the dSYM path we find if it starts with a tilde.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@165299 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
63e5cf65c43615da20b272fde2a21ffd4fa6eb29 03-Oct-2012 Jason Molenda <jmolenda@apple.com> Change DynamicLoaderDarwinKernel::OSKextLoadedKextSummary to use
the Symbols::LocateExecutableObjectFile method to locate kexts and
kernels instead of copying them out of the memory of the remote
system. This is the fix for <rdar://problem/12416384>.

Fix a variable shadowing problem in
Symbols::LocateMacOSXFilesUsingDebugSymbols which caused the symbol
rich executable binaries to not be found even if they were listed
in the dSYM Info.plist.

Change Symbols::DownloadObjectAndSymbolFile to ignore dsymForUUID's
negative cache - this is typically being called by the user and we
should try even if there's a incorrect entry in the negative cache.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@165061 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
437b5bccea45a5981edbbbeb4e23424aec4ce774 28-Sep-2012 Greg Clayton <gclayton@apple.com> Wrapped up the work I am going to do for now for the "add-dsym" or "target symfile add" command.

We can now do:

Specify a path to a debug symbols file:
(lldb) add-dsym <path-to-dsym>

Go and download the dSYM file for the "libunc.dylib" module in your target:
(lldb) add-dsym --shlib libunc.dylib

Go and download the dSYM given a UUID:
(lldb) add-dsym --uuid <UUID>

Go and download the dSYM file for the current frame:
(lldb) add-dsym --frame



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@164806 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
b924eb6c5250a9909dc55ac736d231f7ccae423b 27-Sep-2012 Greg Clayton <gclayton@apple.com> Added the ability to download a symboled executable and symbol file given a UUID.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@164753 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
95b765e8000b44644d021e95bc58eac95028573b 12-Sep-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/11374963>

Partial fix for the above radar where we now resolve dsym mach-o files within the dSYM bundle when using "add-dsym" through the platform.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@163676 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
49ce8969d3154e1560106cfe530444c09410f217 29-Aug-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/11757916>

Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file".
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()

Cleaned up header includes a bit as well.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@162860 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
9262cd52e254fb261334254a80a1b316d59b555c 22-Aug-2012 Johnny Chen <johnny.chen@apple.com> rdar://problem/11324515

'add-dsym' (aka 'target symbols add') should display error messages when dsym file is not found
or the dsym uuid does not match any existing modules. Add TestAddDsymCommand.py test file.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@162332 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
4d8c5434779393d5502b45f42a9371477604aab7 13-Jul-2012 Greg Clayton <gclayton@apple.com> Resolve source paths that start with ~ when doing substitutions.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@160158 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
78c180ab423d3a802566d49a41363b132f20c907 06-May-2012 Filipe Cabecinhas <me@filcab.net> Fixed some strncat/strlcat uses.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@156264 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
964deba8853eb794e59263322b59b09b43669618 15-Mar-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/8196933>

Use the metadata in the dSYM bundle Info.plist to remap source paths when they keys are available.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@152836 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
444fe998bf707bd076a70c3a779db8575533695e 26-Feb-2012 Greg Clayton <gclayton@apple.com> Made a ModuleSpec class in Module.h which can specify a module using one or
more of the local path, platform path, associated symbol file, UUID, arch,
object name and object offset. This allows many of the calls that were
GetSharedModule to reduce the number of arguments that were used in a call
to these functions. It also allows a module to be created with a ModuleSpec
which allows many things to be specified prior to any accessors being called
on the Module class itself.

I was running into problems when adding support for "target symbol add"
where you can specify a stand alone debug info file after debugging has started
where I needed to specify the associated symbol file path and if I waited until
after construction, the wrong symbol file had already been located. By using
the ModuleSpec it allows us to construct a module with as little or as much
information as needed and not have to change the parameter list.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151476 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
9ce953807eb814a93b449dc243de4f7bf32c3115 14-Feb-2012 Greg Clayton <gclayton@apple.com> Full core file support has been added for mach-o core files.

Tracking modules down when you have a UUID and a path has been improved.

DynamicLoaderDarwinKernel no longer parses mach-o load commands and it
now uses the memory based modules now that we can load modules from memory.

Added a target setting named "target.exec-search-paths" which can be used
to supply a list of directories to use when trying to look for executables.
This allows one or more directories to be used when searching for modules
that may not exist in the SDK/PDK. The target automatically adds the directory
for the main executable to this list so this should help us in tracking down
shared libraries and other binaries.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@150426 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
cbf1591dd5b3d9d364d401bd857241bde198b645 01-Feb-2012 Johnny Chen <johnny.chen@apple.com> lldb should warn when dSYM does not match the binary.

o Symbols.cpp:

Emit a warning message when dSYM does not match the binary.

o warnings/uuid:

Added regression test case.

o lldbtest.py:

Modified to allow test case writer to demand that the build command does not begin
with a clean first; required to make TestUUIDMismatchWanring.py work.

rdar://problem/10515708


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@149465 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
db2dc2b824b61ef7578dc8cdad7b338aa82b1f17 12-Jan-2012 Greg Clayton <gclayton@apple.com> Big change in the way ObjectFile file contents are managed. We now
mmap() the entire object file contents into memory with MAP_PRIVATE.
We do this because object file contents can change on us and currently
this helps alleviate this situation. It also make the code for accessing
object file data much easier to manage and we don't end up opening the
file, reading some data and closing the file over and over.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@148017 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
3e4238d47a6d1a3106f357d2e7b495870721c7ae 04-Nov-2011 Greg Clayton <gclayton@apple.com> Fixed the Xcode project building of LLVM to be a bit more user friendly:

- If you download and build the sources in the Xcode project, x86_64 builds
by default using the "llvm.zip" checkpointed LLVM.
- If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the
Xcode project will download the right LLVM sources and build them from
scratch
- If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib"
directory, we will use the sources you have placed in the LLDB directory.

Python can now be disabled for platforms that don't support it.

Changed the way the libllvmclang.a files get used. They now all get built into
arch specific directories and never get merged into universal binaries as this
was causing issues where you would have to go and delete the file if you wanted
to build an extra architecture slice.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@143678 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
a1ebbd2410cafb890ab8519ae4e6b24cc618bd6a 31-Oct-2011 Daniel Dunbar <daniel@zuster.org> build: Fix an improperly formed include path (works under Xcode's promiscuous include additions, but not Makefiles).

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@143382 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
0fa512447e00da09d300fbabd18b5ce94f52fdaa 19-Jul-2011 Greg Clayton <gclayton@apple.com> Modified the LocateMacOSXFilesUsingDebugSymbols(...) function to locate
an executable file if it is right next to a dSYM file that is found using
DebugSymbols. The code also looks into a bundle if the dSYM file is right
next to a bundle.

Modified the MacOSX kernel dynamic loader plug-in to correctly set the load
address for kext sections. This is a tad tricky because of how LLDB chooses
to treat mach-o segments with no name. Also modified the loader to properly
handle the older version 1 kext summary info.

Fixed a crasher in the Mach-o object file parser when it is trying to set
the section size correctly for dSYM sections.

Added packet dumpers to the CommunicationKDP class. We now also properly
detect address byte sizes based on the cpu type and subtype that is provided.
Added a read memory and read register support to CommunicationKDP. Added a
ThreadKDP class that now uses subclasses of the RegisterContextDarwin_XXX for
arm, i386 and x86_64.

Fixed some register numbering issues in the RegisterContextDarwin_arm class
and added ARM GDB numbers to the ARM_GCC_Registers.h file.

Change the RegisterContextMach_XXX classes over to subclassing their
RegisterContextDarwin_XXX counterparts so we can share the mach register
contexts between the user and kernel plug-ins.




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@135466 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
b72d0f098e45936fa72e26b1a026c603e17e2d6c 12-Apr-2011 Greg Clayton <gclayton@apple.com> Moved the execution context that was in the Debugger into
the CommandInterpreter where it was always being used.

Make sure that Modules can track their object file offsets correctly to
allow opening of sub object files (like the "__commpage" on darwin).

Modified the Platforms to be able to launch processes. The first part of this
move is the platform soon will become the entity that launches your program
and when it does, it uses a new ProcessLaunchInfo class which encapsulates
all process launching settings. This simplifies the internal APIs needed for
launching. I want to slowly phase out process launching from the process
classes, so for now we can still launch just as we used to, but eventually
the platform is the object that should do the launching.

Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able
to launch processes with all of the new eLaunchFlag settings. Modified any
code that was manually launching processes to use the Host::LaunchProcess
functions.

Fixed an issue where lldb_private::Args had implicitly defined copy
constructors that could do the wrong thing. This has now been fixed by adding
an appropriate copy constructor and assignment operator.

Make sure we don't add empty ModuleSP entries to a module list.

Fixed the commpage module creation on MacOSX, but we still need to train
the MacOSX dynamic loader to not get rid of it when it doesn't have an entry
in the all image infos.

Abstracted many more calls from in ProcessGDBRemote down into the
GDBRemoteCommunicationClient subclass to make the classes cleaner and more
efficient.

Fixed the default iOS ARM register context to be correct and also added support
for targets that don't support the qThreadStopInfo packet by selecting the
current thread (only if needed) and then sending a stop reply packet.

Debugserver can now start up with a --unix-socket (-u for short) and can
then bind to port zero and send the port it bound to to a listening process
on the other end. This allows the GDB remote platform to spawn new GDB server
instances (debugserver) to allow platform debugging.







git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@129351 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
940b103224f3062578c7a7e6e76d8bf4a7956f2a 23-Feb-2011 Greg Clayton <gclayton@apple.com> Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form
of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up
doing was:
- Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics
the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple
to give us the machine type from llvm::Triple::ArchType.
- There is a new ArchSpec::Core definition which further qualifies the CPU
core we are dealing with into a single enumeration. If you need support for
a new Core and want to debug it in LLDB, it must be added to this list. In
the future we can allow for dynamic core registration, but for now it is
hard coded.
- The ArchSpec can now be initialized with a llvm::Triple or with a C string
that represents the triple (it can just be an arch still like "i386").
- The ArchSpec can still initialize itself with a architecture type -- mach-o
with cpu type and subtype, or ELF with e_machine + e_flags -- and this will
then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core.
The mach-o cpu type and subtype can be accessed using the getter functions:

uint32_t
ArchSpec::GetMachOCPUType () const;

uint32_t
ArchSpec::GetMachOCPUSubType () const;

But these functions are just converting out internal llvm::Triple::ArchSpec
+ ArchSpec::Core back into mach-o. Same goes for ELF.

All code has been updated to deal with the changes.

This should abstract us until later when the llvm::TargetSpec stuff gets
finalized and we can then adopt it.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@126278 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
17f5afe9ed10bda3efbce0f26cf0c030331f8b15 05-Feb-2011 Greg Clayton <gclayton@apple.com> Header patch, virtual dtor patch and missed UUID patch from Kirk Beitz.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@124931 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
0467c78e9a75eff9ec33d3c1f39fa83e1c5d9241 04-Feb-2011 Greg Clayton <gclayton@apple.com> Applied a fix to qualify "UUID" with the lldb_private namespace to fix
build issues on MinGW.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@124888 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
52fd984f7e67c3a0ab18d5565f40356bcfa84822 02-Feb-2011 Greg Clayton <gclayton@apple.com> 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.





git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@124716 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
ad400274d4e3ed01a4c730e1d6f95e6cb2ac73dc 01-Feb-2011 Greg Clayton <gclayton@apple.com> Added a cleanup helper object to make sure the directory that was opened with "DIR *opendir(const char *)" is closed if it is valid with a call to "int closedir (DIR *)".

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@124648 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
cd548034fa23113e995b8463d14f910ba2f7298c 01-Feb-2011 Greg Clayton <gclayton@apple.com> Endian patch from Kirk Beitz that allows better cross platform building.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@124643 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
537a7a86687683fd403ce652d178fbc89e06ef9f 20-Oct-2010 Greg Clayton <gclayton@apple.com> Fixed an issue where we were resolving paths when we should have been.

So the issue here was that we have lldb_private::FileSpec that by default was
always resolving a path when using the:

FileSpec::FileSpec (const char *path);

and in the:

void FileSpec::SetFile(const char *pathname, bool resolve = true);

This isn't what we want in many many cases. One example is you have "/tmp" on
your file system which is really "/private/tmp". You compile code in that
directory and end up with debug info that mentions "/tmp/file.c". Then you
type:

(lldb) breakpoint set --file file.c --line 5

If your current working directory is "/tmp", then "file.c" would be turned
into "/private/tmp/file.c" which won't match anything in the debug info.
Also, it should have been just a FileSpec with no directory and a filename
of "file.c" which could (and should) potentially match any instances of "file.c"
in the debug info.

So I removed the constructor that just takes a path:

FileSpec::FileSpec (const char *path); // REMOVED

You must now use the other constructor that has a "bool resolve" parameter that you must always supply:

FileSpec::FileSpec (const char *path, bool resolve);

I also removed the default parameter to SetFile():

void FileSpec::SetFile(const char *pathname, bool resolve);

And fixed all of the code to use the right settings.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@116944 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
3a4ea24572fad1e22525f8efb718d49d41e30398 10-Sep-2010 Jason Molenda <jmolenda@apple.com> 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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@113581 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
5bc7b67ccc8bb4a977d129e51313067dcbc7bb94 09-Sep-2010 Chris Lattner <sabre@nondot.org> eliminate some clang warnings.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@113438 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
1674b12bbc3dae7b9543b8c5f958e90ddc767fa4 22-Jul-2010 Greg Clayton <gclayton@apple.com> Change over to using the definitions for mach-o types and defines to the
defines that are in "llvm/Support/MachO.h". This should allow ObjectFileMachO
and ObjectContainerUniversalMachO to be able to be cross compiled in Linux.

Also did some cleanup on the ASTType by renaming it to ClangASTType and
renaming the header file. Moved a lot of "AST * + opaque clang type *"
functionality from lldb_private::Type over into ClangASTType.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@109046 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
54e7afa84d945f9137f9372ecde432f9e1a702fc 09-Jul-2010 Greg Clayton <gclayton@apple.com> Merged Eli Friedman's linux build changes where he added Makefile files that
enabled LLVM make style building and made this compile LLDB on Mac OS X. We
can now iterate on this to make the build work on both linux and macosx.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@108009 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
cf0150574a0a97049efe2dce2cc0aa433705feb3 11-Jun-2010 Greg Clayton <gclayton@apple.com> Made lldb_private::ArchSpec more generic so that it can take a mach-o cpu
type and sub-type, or an ELF e_machine value. Also added a generic CPU type
to the arch spec class so we can have a single arch definition that the LLDB
core code can use. Previously a lot of places in the code were using the
mach-o definitions from a macosx header file.

Switches over to using "llvm/Support/MachO.h" for the llvm::MachO::XXX for the
CPU types and sub types for mach-o ArchSpecs. Added "llvm/Support/ELF.h" so
we can use the "llvm::ELF::XXX" defines for the ELF ArchSpecs.

Got rid of all CPU_TYPE_ and CPU_SUBTYPE_ defines that were previously being
used in LLDB.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@105806 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp
24943d2ee8bfaa7cf5893e4709143924157a5c1e 08-Jun-2010 Chris Lattner <sabre@nondot.org> Initial checkin of lldb code from internal Apple repo.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@105619 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Host/macosx/Symbols.cpp