diff options
author | Jason Molenda <jmolenda@apple.com> | 2015-10-01 05:37:22 +0000 |
---|---|---|
committer | Jason Molenda <jmolenda@apple.com> | 2015-10-01 05:37:22 +0000 |
commit | 8b2f23d51541748501edf645c32ff27c1f6d9fb2 (patch) | |
tree | 5208a0c1aeaccc3491fdf5bd0f88827984ef269d /lldb/source/Plugins/Process/MacOSX-Kernel | |
parent | aca0e58caad351c95eee5ca7ac83c4daf9c48615 (diff) | |
download | bcm5719-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.cpp | 8 |
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); |