ObjectFileMachO: Prioritize the TEXT segment as the mach header segment, regardless of the order the segments appear in the file

[jasonmolenda]

Summary

ObjectFileMachO::GetMachHeaderSection() is used to find the vmaddr of the mach-o header of a binary. It first scans all of the Mach-O segments looking for one at file offset 0. Then it finds no segments at file offset 0 (e.g. binaries in a shared cache), it looks for a segment called __TEXT.

I have an unusual situation where I need to work with a binary where it is laid out in virtual memory the traditional order, TEXT, DATA, LINKEDIT. But the Mach-O binary is ordered DATA, LINKEDIT, TEXT. I would like to argue that while technically allowed, no one does this, but there is no part of the Mach-O standard that forbids such a binary, and lldb needs to roll with it.

I'm moving the search for a segment called "TEXT" to be the first thing we try, and failing that, look for a segment with file offset 0. I don't have any such binary I can include as a test case publicly, so I can't add a test for this specific case right now.

Another possible approach would be to sort the segments by vmaddr order and take the one with the lowest vmaddr as being the mach-o header. It would be a valid approach too, but I haven't stress tested this idea and am reluctant to try something novel when the existing shared cache style search works correctly if we prioritize it ahead of fileoff==0 search.

rdar://109128418

[jingham]

LGTM for support of something that really should hurt a little more than you are making it...

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

Section *ObjectFileMachO::GetMachHeaderSection() {
   // the mach-o file which can be subtracted from the vmaddr of the other
   // segments found in memory and added to the load address
   ModuleSP module_sp = GetModule();
   if (!module_sp)
     return nullptr;
   SectionList *section_list = GetSectionList();
   if (!section_list)
     return nullptr;
+
+  // Some binaries can have a TEXT segment with a non-zero file offset.
+  // Binaries in the shared cache are one example.  Some hand-generated
+  // binaries may not be laid out in the normal TEXT,DATA,LC_SYMTAB order
+  // in the file, even though they're laid out correctly in vmaddr terms.
+  SectionSP text_segment_sp =
+      section_list->FindSectionByName(GetSegmentNameTEXT());
+  if (text_segment_sp.get() && SectionIsLoadable(text_segment_sp.get()))
+    return text_segment_sp.get();
+
   const size_t num_sections = section_list->GetSize();
   for (size_t sect_idx = 0; sect_idx < num_sections; ++sect_idx) {
     Section *section = section_list->GetSectionAtIndex(sect_idx).get();
     if (section->GetFileOffset() == 0 && SectionIsLoadable(section))
       return section;
   }
 
-  // We may have a binary in the shared cache that has a non-zero
-  // file address for its first segment, traditionally the __TEXT segment.
-  // Search for it by name and return it as our next best guess.
-  SectionSP text_segment_sp =
-      GetSectionList()->FindSectionByName(GetSegmentNameTEXT());
-  if (text_segment_sp.get() && SectionIsLoadable(text_segment_sp.get()))
-    return text_segment_sp.get();
-
   return nullptr;
 }
 
 bool ObjectFileMachO::SectionIsLoadable(const Section *section) {
   if (!section)
     return false;
   const bool is_dsym = (m_header.filetype == MH_DSYM);
   if (section->GetFileSize() == 0 && !is_dsym)