[PATCH] D95730: [MC] Support SHF_GNU_RETAIN as section flag 'R'

[Peter Smith via Phabricator via llvm-commits]

psmith accepted this revision.
psmith added a comment.
This revision is now accepted and ready to land.

Code changes and test LGTM. The OSABI question is interesting, I don't have a particular good answer or suggestion, the whole area is a bit of a mess. Looking at what ELF says:

  EI_OSABI
  Byte e_ident[EI_OSABI] identifies the OS- or ABI-specific ELF extensions used by this file. Some fields in other ELF structures have flags and values that have operating system and/or ABI specific meanings; the interpretation of those fields is determined by the value of this byte. If the object file does not use any extensions, it is recommended that this byte be set to 0. If the value for this byte is 64 through 255, its meaning depends on the value of the e_machine header member. The ABI processor supplement for an architecture can define its own associated set of values for this byte in this range. If the processor supplement does not specify a set of values, one of the following values shall be used, where 0 can also be taken to mean unspecified.

The flag is in the OS specific range so it could clash with other OS specific flags, to be strictly compliant it should set an OSABI to avoid clashes. It is unfortunate that we can only set one value though. For example the Arm processor supplement defines a couple of OSABI flags. What is the combination of using a GNU OS specific flag? I think ELF is implying that OSABI should be set to GNU if there is no processor specific OSABI value, I guess a strictly compliant toolchain would not permit SHF_RETAIN if there is some other OSABI in action that doesn't also recognise SHF_RETAIN. Quite how practical that is, and how strictly it has been followed in the past is another matter though.

I guess if ELF were still active, then SHF_RETAIN could be a standard ELF flag not an OS specific one.

As to what the linker should do. I think that unless there is a clash with some other OS specific flag that needs disambiguating it seems like accepting SHF_RETAIN (which is more toolchain than OS) when OSABI is 0 seems reasonable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95730