[PATCH] D60189: [llvm-objcopy] Simplify SHT_NOBITS -> SHT_PROGBITS promotion

[Fangrui Song via Phabricator via llvm-commits]

MaskRay added a comment.

About the rule used in this patch: `(!(Sec.Flags & ELF::SHF_ALLOC) || Flags & (SectionFlag::SecContents | SectionFlag::SecLoad)))`

`!(Sec.Flags & ELF::SHF_ALLOC)`
-------------------------------

The rationale is in the description.

`SectionFlag::SecContents`
--------------------------

In `binutils-gdb/bfd/sections.c`, the comment of `SEC_HAS_CONTENTS` is ".The section has contents - a data section could be .  <<SEC_ALLOC>> | <<SEC_HAS_CONTENTS>>; a debug section could be .  <<SEC_HAS_CONTENTS>>". This bit corresponds to our `SecContents`. If the user puts some stuff to the section, it can no longer be `SHT_NOBITS` (gABI says "A section of type SHT_NOBITS may have a non-zero size, but it occupies no space in the file.") This bit makes much sense to promote `SHT_NOBITS` -> `SHT_PROGBITS`.

`SectionFlag::SecLoad`
----------------------

The comment of `SEC_LOAD` is "Tells the OS to load the section from the file when loading. This is clear for a .bss section." `.bss` is of `SHT_NOBITS`. I feel this rule still makes sense, but not much as `SEC_HAS_CONTENTS` does.

The other bits `SectionFlag::SecCode | SectionFlag::SecData | ...` make less sense thus they are remove from this patch.

Since llvm-objcopy contributors are adding more and more GNU objcopy options to llvm-objcopy, I feel people care about its compatibility with GNU objcopy. My preference is actually to keep just `SectionFlag::SecContents` and drop the other two, if I'm allowed to do so. This would certainly harm compatibility with GNU objcopy. What do people think?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D60189