When scanning mach-o corefile, don't run all DynamicLoader plugins letting one of them Create when searching for binaries

[jasonmolenda]

Summary

In https://reviews.llvm.org/D133680 I changed a lot of how ProcessMachCore scans a corefile to figure out what kind of debug session this is (kernel, firmware, userland, etc) and where the binaries are. ProcessMachCore::LoadBinariesViaMetadata() calls ObjectFile::LoadCoreFileImages(), and under there, it is possible that the Process DynamicLoader will be set in the process of its scans. Then back in LoadBinariesViaMetadata() it would check to see if the dynamic loader had been set. It would do this by calling ProcessMachCore::GetDynamicLoader(), but this method, if m_dyld_up is empty, will call the plugin interface FindPlugin method with the minimal amount of information we have so far --- and pick the wrong dynamic loader plugin for a userland process.

This broke userland corefile loading in lldb; no the DynamicLoaderMacOSX plugin is not loaded, so we don't load any of the binaries in the corfile. It's not a very commonly used type of corefile on Darwin systems, so it slipped by. The corefiles created by lldb's process save-core include a lot of metadata which make this work correctly for them, so it didn't get caught by the testsuite.

The fix is to change the call to GetDynamicLoader() which can *set* the dynamic loader, and instead look at the ivar. This is the only call to this method inside ProcessMachCore's methods.

[JDevlieghere]

LGTM

lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp

334

if (m_dyld_up)

[jasonmolenda]

Thanks Jonas.

[jasonmolenda]

Jonas' feedback

lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp

       }
     }
   }
 
   // Finally, load any binaries noted by "load binary" LC_NOTEs in the
   // corefile
   core_objfile->LoadCoreFileImages(*this);
 
-  // LoadCoreFileImges may have set the dynamic loader; if we now have
-  // a dynamic loader, save its name so we don't un-set it later.
-  if (GetDynamicLoader())
+  // LoadCoreFileImges may have set the dynamic loader, e.g. in
+  // PlatformDarwinKernel::LoadPlatformBinaryAndSetup().
+  // If we now have a dynamic loader, save its name so we don't 
+  // un-set it later.
+  if (m_dyld_up.get())
     m_dyld_plugin_name = GetDynamicLoader()->GetPluginName();
 }
 
 void ProcessMachCore::LoadBinariesViaExhaustiveSearch() {
   Log *log(GetLog(LLDBLog::DynamicLoader | LLDBLog::Process));
 
   // Search the pages of the corefile for dyld or mach kernel
   // binaries.  There may be multiple things that look like a kernel