hanchenye-llvm-project/lldb/source/Host
Jason Molenda 8825c5c9b4 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
2015-10-08 21:48:35 +00:00
..
android [linux] Use cmake to detect support process_vm_readv (bug #23918) 2015-06-29 09:18:17 +00:00
common Re-commit the (fixed) changes from r248985 which were reverted by Pavel 2015-10-08 21:48:35 +00:00
freebsd [Makefiles] Align library names with CMake build 2015-07-14 20:25:19 +00:00
linux Do not use pthread_setname_np() if we don't have GLIBC or Android. 2015-09-22 14:52:31 +00:00
macosx Re-commit the (fixed) changes from r248985 which were reverted by Pavel 2015-10-08 21:48:35 +00:00
posix Moved ResolveSymbolicLink() to the FileSystem where it belongs, thanks 2015-09-18 22:24:57 +00:00
windows Moved ResolveSymbolicLink() to the FileSystem where it belongs, thanks 2015-09-18 22:24:57 +00:00
CMakeLists.txt Move GetOptInc to the common namespace 2015-09-04 09:06:15 +00:00
Makefile [Makefiles] Re-add OSX specific code that got lost in lldbHost consolidation 2015-07-17 21:47:35 +00:00