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

[George Rimar via Phabricator via llvm-commits]

grimar added a comment.

In D93678#2476962 <https://reviews.llvm.org/D93678#2476962>, @jhenderson wrote:

> 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.

My concern is that it might hurt readability of some of our test cases, where we have a correlation between section addresses/sizes and offsets (an often case I think):
if we will have the "Offset" aspect in "Layout" and "Address"/"Size"/"Content" in "Sections", it makes more difficult to adjust them as "Size"/"Content" affects on "Offset" directly. And the latter one affects on "Address".

Another concern is that having 2 lists might cause the confusion: currently we place sections in the order they are mentioned in "Sections".
With this new scheme I assume the order from "Layout" will be used and the order of sections in "Sections" becomes not important. It feels slightly more complicated, e.g.
people might try to describe program headers using the "Sections", though they need to use the "Layout". We might add the check to verify that the order is synchronized of course, but still...

Personally I'd prefer the first option you mentioned.
Also, if we think about `Symbols` and `DynamicSymbols` keys: currently it is impossible to describe
multiple symbol tables, because `Symbols` is implicitly attached to `.symtab` and `DynamicSymbols` is attached to `.dynsym`.
Though instead we could move them to allow describing multiple symbol tables and the whole structure might look like:

  --- !ELF
  FileHeader:
    Class:   ELFCLASS32
    Data:    ELFDATA2LSB
    Type:    ET_REL
    Machine: EM_386
  Layout:
    - ProgramHeaderTable:
        Offset: 0x100
        ProgramHeaders:
          - Type: PT_LOAD
          - Type: PT_LOAD
          ...
    - Section:
      Type: SHT_PROGBITS
      Name: .foo
      Offset: 0x200
    - Type: Fill
      Offset: 0x1000
      Size: 0x20
    - Name: .symtab
      Type: SHT_SYMTAB
      Symbols:
        - Type:  STT_SECTION
          Index: 0
    - Name: .dynsym_custom
      Type: SHT_DYNSYM
      Symbols:
        - Name: foo
    - Name: .dynsym
      Type: SHT_DYNSYM
      Symbols:
        - Name: foo
        - Name: bar
    - SectionHeaderTable:
      ...




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

https://reviews.llvm.org/D93678