summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/MacOSX-Kernel
diff options
context:
space:
mode:
authorJason Molenda <jmolenda@apple.com>2015-10-01 05:37:22 +0000
committerJason Molenda <jmolenda@apple.com>2015-10-01 05:37:22 +0000
commit8b2f23d51541748501edf645c32ff27c1f6d9fb2 (patch)
tree5208a0c1aeaccc3491fdf5bd0f88827984ef269d /lldb/source/Plugins/Process/MacOSX-Kernel
parentaca0e58caad351c95eee5ca7ac83c4daf9c48615 (diff)
downloadbcm5719-llvm-8b2f23d51541748501edf645c32ff27c1f6d9fb2.tar.gz
bcm5719-llvm-8b2f23d51541748501edf645c32ff27c1f6d9fb2.zip
Fixing a subtle issue on Mac OS X systems with dSYMs (possibly
introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 248985
Diffstat (limited to 'lldb/source/Plugins/Process/MacOSX-Kernel')
-rw-r--r--lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp8
1 files changed, 7 insertions, 1 deletions
diff --git a/lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp b/lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp
index 6e1dc5bde90..b3dca1f20ab 100644
--- a/lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp
+++ b/lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp
@@ -321,7 +321,13 @@ ProcessKDP::DoConnectRemote (Stream *strm, const char *remote_url)
// Lookup UUID locally, before attempting dsymForUUID like action
module_spec.GetSymbolFileSpec() = Symbols::LocateExecutableSymbolFile(module_spec);
if (module_spec.GetSymbolFileSpec())
- module_spec.GetFileSpec() = Symbols::LocateExecutableObjectFile (module_spec);
+ {
+ ModuleSpec executable_module_spec = Symbols::LocateExecutableObjectFile (module_spec);
+ if (executable_module_spec.GetFileSpec().Exists())
+ {
+ module_spec.GetFileSpec() = executable_module_spec.GetFileSpec();
+ }
+ }
if (!module_spec.GetSymbolFileSpec() || !module_spec.GetSymbolFileSpec())
Symbols::DownloadObjectAndSymbolFile (module_spec, true);
OpenPOWER on IntegriCloud