[PATCH] D95591: [yaml2obj/obj2yaml] - Implement program header table as a special Chunk.

[Pavel Labath via Phabricator via llvm-commits]

labath added a comment.

In D95591#2533380 <https://reviews.llvm.org/D95591#2533380>, @jhenderson wrote:

> @grimar is on vacation for an extended period, so I'll take over the design discussion from him, since I worked with him on coming up with the design. Below, I summarise the key design ideas, to make sure we're all on the same page.
>
> At some point, I think we want to change `Sections:` to `Layout:`, to avoid confusion. Due to the invasiveness of this change, I think we wanted to get the member design done first, and possibly even keep `Sections:` as an alias.
>
> This block is now used to control (with this patch) placement of 4 different kinds of things (called "chunks" in the code): sections, fills, the section header table, and the program header table. These would be distinguished by their `Type` field. `Fill`, `SectionHeaderTable` and `ProgramHeaderTable` have special meanings. All others represent some kind of section. The Type field then drives the meaning of the rest of the chunk. All four types share the same Offset behaviour (it is automatically calculated unless explicitly specified). This means we can control placement of all components of an ELF object, except for the file header itself, which needs to be at a fixed location anyway.
>
> As we all know, fills are for creating gaps in the output, and sections are for defining the section header properties and contents of a section. The ProgramHeaderTable chunk simply describes the program headers in the ELF, in the same way as the old ProgramHeaders key functioned before. Finally, the SectionHeaderTable chunk type is for describing that table. In particular, it provides the ability to control the order of the section headers, as well as whether some or all headers should be omitted from the table. The latter feature is useful for writing arbitrary contents in section form, without needing the data visible to tools via the section header. Note that the section header order is independent of the section data order. The `Sections:` ordering provides the data ordering. Thus a section header could appear last in the table, but the data might be first in the ELF (after the file header).

Thanks for summarizing this. I haven't been keeping track of recent yaml2obj changes, but all of this looks extremely nice and useful to me. The main functionality I am missing is the ability to (de)serialize core files (no sections, all info is given through program headers and notes), and it sounds like this comes really close to making that possible.

> As noted above, by using the existing Type field to recognise special chunk kinds, and then with the default behaviour being to interpret the value as some section type, I don't think we need an extra line.

Interesting. It slightly overloads the meaning of the "Type" field, but I guess it does make the common case simpler.


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

https://reviews.llvm.org/D95591