Add a new setting (currently fixed) for how to

interpret core files that contain both a user
process dyld and a kernel executable in them.
Fix an additional method that needs to be 
adjusted depending on this preference as well.
<rdar://problem/15721409> 

llvm-svn: 197931

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

@@ -306,28 +306,29 @@ ProcessMachCore::DoLoadCore ()
         }
     }
 
-    // If we find both a user process dyld and a mach kernel, we need to pick which one to use.
+    // If we found both a user-process dyld and a kernel binary, we need to decide
-    // We're looking at one or two scenarios:
+    // which to prefer.
-    //
+    if (GetCorefilePreference() == eKernelCorefile)
-    // 1 This is a core of a crashed user process (e.g. a debugger) which has a copy of 
-    //   a kernel in its memory.  lldb crashed while doing kernel debugging, leaving this 
-    //   core file behind.
-    //
-    // 2 This is a kernel core file that happens to have a user-land dyld macho image in
-    //   one of its vm pages.
-    //
-    // #2 is rare, but has happened.  #1 only happens to people debugging the debugger, so
-    // for now, they will be inconvenienced.  FIXME - we should have a ProcessMachCore 
-    // default setting to specify which dynamic loader to use so it can over-ridden without
-    // rebuilding the debugger for those rare occasions where it's needed.
-
-    if (m_mach_kernel_addr != LLDB_INVALID_ADDRESS)
     {
-        m_dyld_plugin_name = DynamicLoaderDarwinKernel::GetPluginNameStatic();
+        if (m_mach_kernel_addr != LLDB_INVALID_ADDRESS)
+        {
+            m_dyld_plugin_name = DynamicLoaderDarwinKernel::GetPluginNameStatic();
+        }
+        else if (m_dyld_addr != LLDB_INVALID_ADDRESS)
+        {
+            m_dyld_plugin_name = DynamicLoaderMacOSXDYLD::GetPluginNameStatic();
+        }
     }
-    else if (m_dyld_addr != LLDB_INVALID_ADDRESS)
+    else
     {
-        m_dyld_plugin_name = DynamicLoaderMacOSXDYLD::GetPluginNameStatic();
+        if (m_dyld_addr != LLDB_INVALID_ADDRESS)
+        {
+            m_dyld_plugin_name = DynamicLoaderMacOSXDYLD::GetPluginNameStatic();
+        }
+        else if (m_mach_kernel_addr != LLDB_INVALID_ADDRESS)
+        {
+            m_dyld_plugin_name = DynamicLoaderDarwinKernel::GetPluginNameStatic();
+        }
     }
 
     // Even if the architecture is set in the target, we need to override
@@ -469,9 +470,24 @@ ProcessMachCore::Initialize()
 addr_t
 ProcessMachCore::GetImageInfoAddress()
 {
-    if (m_dyld_addr != LLDB_INVALID_ADDRESS)
+    // If we found both a user-process dyld and a kernel binary, we need to decide
+    // which to prefer.
+    if (GetCorefilePreference() == eKernelCorefile)
+    {
+        if (m_mach_kernel_addr)
+        {
+            return m_mach_kernel_addr;
+        }
         return m_dyld_addr;
-    return m_mach_kernel_addr;
+    }
+    else
+    {
+        if (m_dyld_addr)
+        {
+            return m_dyld_addr;
+        }
+        return m_mach_kernel_addr;
+    }
 }
 
 

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

@@ -127,6 +127,28 @@ private:
     bool 
     GetDynamicLoaderAddress (lldb::addr_t addr);
 
+    typedef enum CorefilePreference { eUserProcessCorefile, eKernelCorefile } CorefilePreferences;
+
+    //------------------------------------------------------------------
+    /// If a core file can be interpreted multiple ways, this establishes
+    /// which style wins.
+    ///
+    /// If a core file contains both a kernel binary and a user-process
+    /// dynamic loader, lldb needs to pick one over the other.  This could
+    /// be a kernel corefile that happens to have a coyp of dyld in its
+    /// memory.  Or it could be a user process coredump of lldb while doing
+    /// kernel debugging - so a copy of the kernel is in its heap.  This
+    /// should become a setting so it can be over-ridden when necessary.
+    //------------------------------------------------------------------
+    CorefilePreference
+    GetCorefilePreference ()
+    {
+        // For now, if both user process and kernel binaries a present,
+        // assume this is a kernel coredump which has a copy of a user
+        // process dyld in one of its pages.
+        return eKernelCorefile;
+    }
+
     //------------------------------------------------------------------
     // For ProcessMachCore only
     //------------------------------------------------------------------