We had a situation where a kext was inlined into the kernel,

but still listed in the kernel's kext table with the kernel
binary UUID.  This resulted in the kernel text section being
loaded at the kext address and problems ensuing.  Instead,
if there is a kext with the same UUID as the kernel, lldb
should skip over it.

<rdar://problem/35757689> 

llvm-svn: 319500

1 files changed, 10 insertions, 0 deletions

diff --git a/lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp b/lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
index a82b3fe267b..31f746c1277 100644
--- a/lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
+++ b/lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
@@ -1229,6 +1229,16 @@ bool DynamicLoaderDarwinKernel::ParseKextSummaries(
         break;
       }
     }
+    // If this "kext" entry is actually an alias for the kernel --
+    // the kext was compiled into the kernel or something -- then
+    // we don't want to load the kernel's text section at a different
+    // address.  Ignore this kext entry.
+    if (kext_summaries[new_kext].GetUUID().IsValid() 
+        && m_kernel.GetUUID().IsValid() 
+        && kext_summaries[new_kext].GetUUID() == m_kernel.GetUUID()) {
+      to_be_added[new_kext] = false;
+      break;
+    }
     if (add_this_one) {
       number_of_new_kexts_being_added++;
     }