[PATCH] D93678: [yaml2obj] - Support selecting the location of the section header table.

[James Henderson via Phabricator via llvm-commits]

jhenderson added a comment.

In D93678#2492777 <https://reviews.llvm.org/D93678#2492777>, @grimar wrote:

> In D93678#2476962 <https://reviews.llvm.org/D93678#2476962>, @jhenderson wrote:
>
>> Option 3: Have a separate "Layout" block within the YAML which would allow you to define the layout. It might look a bit like this:
>>
>>   Layout:
>>     - FileHeader
>>     - Section1
>>     - ProgramHeaders
>>     - Section2
>>     - SectionHeaders
>>     - Section3
>>
>> I'm not sure how this option would work alongside `Offset` values for sections, or what should happen if e.g. the file header entry were to be omitted.
>
> If we really want to add a way to select where program headers are placed and also to support placing both program headers and section headers at an arbitrary offsets,
> then I see the following solution:
>
> Currently, internally, we have a list of Chunks, which consists of sections and a special `Fill` chunk.
> If we rename the "Sections" YAML key to "Layout" (or alike), then we might be able to introduce 2 more special optional chunks: `ProgramHeaders` and `SectionHeaders`.
>
> Then we will be able to write YAMLs like this:
>
>   --- !ELF
>   FileHeader:
>     Class: ELFCLASS64
>     Data:  ELFDATA2LSB
>     Type:  ET_DYN
>   Layout:
>     - Name: .section1
>       Type: SHT_PROGBITS
>       Size: 0
>     - Type: SectionHeaders
>        Offset: 0x1000
>     - Name: .section2
>        Type: SHT_PROGBITS
>        Offset: 0x1200
>     - Type: ProgramHeaders
>
> I.e. it might look kind of close to what you've suggested in "Option 3", but doesn't introduce a one more separate YAML block, but allows to reuse the "Sections" block.
>
> Perhaps, we can just have the "Sections" name unchanged for now and think about changing it (or keeping) later, when the functionality will be committed.

Making program headers and the section header table kinds of Chunk makes a lot of sense to me, and I think would fit the design well. Indeed, the general concept is similar to one we already implement in a proprietary objcopy-like tool for performing layout. My main question with this proposal is this: do we want a list (whether called "Layout" or "Sections"), which defines properties of Sections and Fills, but not of the section header table and program header table (apart from their position)? It feels inconsistent to me. We could potentially move the ProgramHeaders and SectionHeaderTable elements into a member of the `Layout` tag, as in the rough example below (exact syntax would need finalising), but I'm not convinced whether it looks nice or not.

  Layout:
    - ProgramHeaderTable:
        Offset: 0x100
        ProgramHeaders:
          - Type: PT_LOAD
          - Type: PT_LOAD
          ...
    - Section:
      Type: SHT_PROGBITS
      Name: .foo
      Offset: 0x200
    - Fill:
      Offset: 0x1000
      Size: 0x20
    - SectionHeaderTable:
      ...

(or similar to what you posted). An alternative would be to move the `Offset` aspect of the sections into the Layout table only, and possibly moving Fills into that Layout block too out of the Sections list. This has the advantage that layout information is generally kept in the Layout table, whilst the details of what a thing actually is (e.g. section type, size, address etc) are kept in appropriate parts of the document. This is closer to my original option 3:

  FileHeader:
    ...
  Sections:
    - Name: .foo
      Type: SHT_PROGBITS
    - Name: .bar
      Type: SHT_PROGBITS
  SectionHeaderTable:
    ...
  ProgramHeaders:
    ...
  Layout:
     - Type: Section
      Name: .foo
      Offset: 0x1000
    - Type: Fill
      # Offset could be implicitly calculated here; fills move out of Sections to Layout.
      Size: 0x100
    - Type: SectionHeaderTable
      Offset: 0x2000
    - Type: ProgramHeaderTable
      Offset: 0x3000
    - Type: Section
      Name: .bar
      Offset: 0x3500

I think I mildly prefer the second one, as it'll be easier to retrofit and feels a little cleaner. We'd need some implicit rules that the program header table appears at the front and the section header table at the back if they aren't specifically mentioned in either case.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93678/new/

https://reviews.llvm.org/D93678