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
This commit is contained in:
Jason Molenda 2013-12-24 02:57:50 +00:00
parent 5e029cecdf
commit 703a45616c
2 changed files with 59 additions and 21 deletions

View File

@ -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.
// We're looking at one or two scenarios:
//
// 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)
// If we found both a user-process dyld and a kernel binary, we need to decide
// which to prefer.
if (GetCorefilePreference() == eKernelCorefile)
{
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;
}
}

View File

@ -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
//------------------------------------------------------------------