[PATCH] D73621: [yaml2obj] - Add a way to set sh_entsize for relocation sections.

[James Henderson via Phabricator via llvm-commits]

jhenderson added a comment.

In D73621#1851587 <https://reviews.llvm.org/D73621#1851587>, @grimar wrote:

> In D73621#1848843 <https://reviews.llvm.org/D73621#1848843>, @grimar wrote:
>
> > In D73621#1848823 <https://reviews.llvm.org/D73621#1848823>, @jhenderson wrote:
> >
> > > Idle thought: I wonder if it's worth introducing some kind of command-line macro option to yaml2obj? E.g. `-DMACHINE=EM_X86_64` would replace `Machine: MACHINE` (or some similar syntax). There are a growing number of cases where we have two identical YAML blobs except for some minor difference.
> >
> >
> > Sounds good. I'd give it a try.
>
>
> One more idea: what if we make `FileHeader` to be optional?
>  e.g. a valid YAML can be something like this:
>
>   --- !ELF
>   Sections:
>   .....
>   Symbols:
>   ....
>
>
> When there is no `FileHeader`, yaml2obj could require `--platform=X` option (or alike) to be specified.
>  It can be similar to linker's `-m` (emulation) option and can accept the same strings for `X`:
>
>     std::pair<ELFKind, uint16_t> ret =
>         StringSwitch<std::pair<ELFKind, uint16_t>>(s)
>             .Cases("aarch64elf", "aarch64linux", "aarch64_elf64_le_vec",
>                    {ELF64LEKind, EM_AARCH64})
>             .Cases("armelf", "armelf_linux_eabi", {ELF32LEKind, EM_ARM})
>   ...
>             .Cases("elf_amd64", "elf_x86_64", {ELF64LEKind, EM_X86_64})
>             .Case("elf_i386", {ELF32LEKind, EM_386})
>             .Case("elf_iamcu", {ELF32LEKind, EM_IAMCU})
>             .Default({ELFNoneKind, EM_NONE});
>
>
> Perhaps we also could add `--elf-type=X` to switch the output type: ET_DYN/ET_REL/ET_EXEC
>  (and have something by default).
>
> A benefit is that we often do not need or use fields of the file header in our tests.
>  Making it optional can reduce the YAML descriptions.


My concern with this approach is that we can keep on adding switches, with very little gain. Taken to an extreme, you could specify sections, symbols, relocations etc via command-line switches and then not have any YAML at all. I don't think that really helps readability. A generic default file header might be okay though, but what would the parameters be? X86_64? ARM? It probably doesn't matter too much, for the cases its used in, but it is perhaps something we should be aware of.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73621