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

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);