[Lldb-commits] [PATCH] D150239: ObjectFileMachO: Prioritize the TEXT segment as the mach header segment, regardless of the order the segments appear in the file

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda created this revision.
jasonmolenda added a reviewer: jingham.
jasonmolenda added a project: LLDB.
Herald added a subscriber: JDevlieghere.
Herald added a project: All.
jasonmolenda requested review of this revision.
Herald added a subscriber: lldb-commits.

`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


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D150239

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


Index: lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
===================================================================
--- lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
@@ -6059,6 +6059,16 @@
   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();
@@ -6066,14 +6076,6 @@
       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;
 }
 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D150239.520886.patch
Type: text/x-patch
Size: 1565 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20230510/8b1bdace/attachment.bin>