Don't treat corefile binaries like dylibs in the shared cache, even if they say they are

[jasonmolenda]

Summary

There is a corefile writer that is including uninitialized data in the Mach-O header 'flags' field. I'll work with them to fix that, but it only causes a problem in one part of lldb today, in ObjectFileMachO::SanitizeSegmentCommand where there is code that is trying to detect an LC_SEGMENT in a binary in the shared cache. The shared cache flag bit is set in this corefile, so we adjust the offsets and the corefile parsing fails big time.

lldb doesn't make a lot of decisions based on the mach header flags field, and even fewer of them when dealing with corefiles, so to handle these corefiles that are floating around, I'd like to add a guard to the code to explicitly opt out when working on a corefile, to work around this.

Fred, this is an edit to your change from last summer in https://reviews.llvm.org/D83023 . Are you OK with this.

lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp

   return result;
 }
 
 void ObjectFileMachO::SanitizeSegmentCommand(segment_command_64 &seg_cmd,
                                              uint32_t cmd_idx) {
   if (m_length == 0 || seg_cmd.filesize == 0)
     return;
 
-  if ((m_header.flags & MH_DYLIB_IN_CACHE) && !IsInMemory()) {
+  if (m_header.filetype != MH_CORE && (m_header.flags & MH_DYLIB_IN_CACHE) &&
+      !IsInMemory()) {
     // In shared cache images, the load commands are relative to the
     // shared cache file, and not the the specific image we are
     // examining. Let's fix this up so that it looks like a normal
     // image.
     if (strncmp(seg_cmd.segname, "__TEXT", sizeof(seg_cmd.segname)) == 0)
       m_text_address = seg_cmd.vmaddr;
     if (strncmp(seg_cmd.segname, "__LINKEDIT", sizeof(seg_cmd.segname)) == 0)
       m_linkedit_original_offset = seg_cmd.fileoff;