Re-commit the (fixed) changes from r248985 which were reverted by Pavel

when they introduced android testsuite regressions.  Pavel has run the
testsuite against the updated patch and it completes cleanly now.

The original commit message:


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: 249755

1 files changed, 14 insertions, 11 deletions

diff --git a/lldb/source/Host/common/Symbols.cpp b/lldb/source/Host/common/Symbols.cpp
index 3fc5aff456a..39c769684fc 100644
--- a/lldb/source/Host/common/Symbols.cpp
+++ b/lldb/source/Host/common/Symbols.cpp
@@ -38,8 +38,7 @@ int
 LocateMacOSXFilesUsingDebugSymbols
 (
     const ModuleSpec &module_spec,
-    FileSpec *out_exec_fspec,   // If non-NULL, try and find the executable
-    FileSpec *out_dsym_fspec    // If non-NULL try and find the debug symbol file
+    ModuleSpec &return_module_spec
 );
 
 #else
@@ -48,8 +47,7 @@ int
 LocateMacOSXFilesUsingDebugSymbols
 (
     const ModuleSpec &module_spec,
-    FileSpec *out_exec_fspec,   // If non-NULL, try and find the executable
-    FileSpec *out_dsym_fspec    // If non-NULL try and find the debug symbol file
+    ModuleSpec &return_module_spec
 ) {
     // Cannot find MacOSX files using debug symbols on non MacOSX.
     return 0;
@@ -178,19 +176,25 @@ LocateExecutableSymbolFileDsym (const ModuleSpec &module_spec)
                         (const void*)uuid);
 
     FileSpec symbol_fspec;
+    ModuleSpec dsym_module_spec;
     // First try and find the dSYM in the same directory as the executable or in
     // an appropriate parent directory
     if (LocateDSYMInVincinityOfExecutable (module_spec, symbol_fspec) == false)
     {
         // We failed to easily find the dSYM above, so use DebugSymbols
-        LocateMacOSXFilesUsingDebugSymbols (module_spec, NULL, &symbol_fspec);
+        LocateMacOSXFilesUsingDebugSymbols (module_spec, dsym_module_spec);
     }
-    return symbol_fspec;
+    else
+    {
+        dsym_module_spec.GetSymbolFileSpec() = symbol_fspec;
+    }
+    return dsym_module_spec.GetSymbolFileSpec();
 }
 
-FileSpec
+ModuleSpec
 Symbols::LocateExecutableObjectFile (const ModuleSpec &module_spec)
 {
+    ModuleSpec result;
     const FileSpec *exec_fspec = module_spec.GetFileSpecPtr();
     const ArchSpec *arch = module_spec.GetArchitecturePtr();
     const UUID *uuid = module_spec.GetUUIDPtr();
@@ -200,20 +204,19 @@ Symbols::LocateExecutableObjectFile (const ModuleSpec &module_spec)
                         arch ? arch->GetArchitectureName() : "<NULL>",
                         (const void*)uuid);
 
-    FileSpec objfile_fspec;
     ModuleSpecList module_specs;
     ModuleSpec matched_module_spec;
     if (exec_fspec &&
         ObjectFile::GetModuleSpecifications(*exec_fspec, 0, 0, module_specs) &&
         module_specs.FindMatchingModuleSpec(module_spec, matched_module_spec))
     {
-        objfile_fspec = exec_fspec;
+        result.GetFileSpec() = exec_fspec;
     }
     else
     {
-        LocateMacOSXFilesUsingDebugSymbols (module_spec, &objfile_fspec, NULL);
+        LocateMacOSXFilesUsingDebugSymbols (module_spec, result);
     }
-    return objfile_fspec;
+    return result;
 }
 
 FileSpec