port(MachO): section/segment mapping and first final output

[marxin]

The second Mach-O port PR implements the concept of sections, segments and I'm able to reach the point a final output file is produced. So far, the designed Platform trait has guided me pretty well.

First, let's start a bit with the Mach-O layout explanation and how I map it to the Wild's essential concepts (PartId that is 1:1 mapping to OutputSectionId; and the ProgramSegmentDef):

The mapping is following:

• Mach Header is part_id::FILE_HEADER
• __TEXT_SEGMENT segment_command_64 is mapped to part_id::TEXT_SEGMENT
• __DATA_SEGMENT segment_command_64 is mapped to part_id::DATA_SEGMENT
• __text section data is mapped to part_id::TEXT
• __data section data is mapped to part_id::DATA

and the following program segments are created (with the clarification how are they used):

• SegmentType::Header - contains only the part_id::FILE_HEADER
• SegmentType::LoadCommand - contains all load commands (__TEXT_SEGMENT, __DATA_SEGMENT, __PAGEZERO_SEGMENT) - we need the information about the number of load commands (and their total size)
• SegmentType::Text - contains __text section content (and will include all other sections defined in __TEXT segment in input files) - based on that we can fill-up the __TEXT_SEGMENT segment_command_64 (number of sections, names, their offset in memory and file)

The suggested approach works fine, except I feel the section iteration of a segment is a bit cumbersome and it heavily depends on the ProgramSegmentDef. I'm going to mark methods in the code that might be improved.

After a small tweak to the ELF part, I was able to introduce an extra Mach-O specific part_ids and so we can basically live with a sparse output section maps. Plus, a lifetime of a method was adjusted based on Mach-O needs.

Right now, I am pretty strict when it comes to the supported segments and sections, but I believe we can get pretty far as the number of used sections is limited. At least to a point, where a simple hello world program will run. Once having that, we can fill the missing gaps.

There are still many cut corners, but it's pretty neat the PR reaches a point where a final output file scaffolding is laid out:

❯ otool -l a.out
a.out:
Load command 0
      cmd LC_SEGMENT_64
  cmdsize 72
  segname __PAGEZERO
   vmaddr 0x0000000000000000
   vmsize 0x0000000100000000
  fileoff 0
 filesize 0
  maxprot 0x00000000
 initprot 0x00000000
   nsects 0
    flags 0x0
Load command 1
      cmd LC_SEGMENT_64
  cmdsize 232
  segname __TEXT
   vmaddr 0x00000000004001e8
   vmsize 0x0000000000000049
  fileoff 488
 filesize 73
  maxprot 0x00000000
 initprot 0x00000000
   nsects 2
    flags 0x0
Section
  sectname __text
   segname __TEXT
      addr 0x00000000004001e8
      size 0x0000000000000038
    offset 488
     align 2^0 (1)
    reloff 0
    nreloc 0
     flags 0x00000000
 reserved1 0
 reserved2 0
Section
  sectname __cstring
   segname __TEXT
      addr 0x0000000000400220
      size 0x0000000000000011
    offset 544
     align 2^0 (1)
    reloff 0
    nreloc 0
     flags 0x00000000
 reserved1 0
 reserved2 0
Load command 2
      cmd LC_SEGMENT_64
  cmdsize 152
  segname __DATA
   vmaddr 0x0000000000400280
   vmsize 0x0000000000000100
  fileoff 640
 filesize 256
  maxprot 0x00000000
 initprot 0x00000000
   nsects 1
    flags 0x0
Section
  sectname __data
   segname __DATA
      addr 0x0000000000400280
      size 0x0000000000000100
    offset 640
     align 2^0 (1)
    reloff 0
    nreloc 0
     flags 0x00000000
 reserved1 0
 reserved2 0

Issue #757