ELF section flag SHF_EXCLUDE

[Mark Wielaard]

Hi,

Adding generic-abi to the CC to see what others think of SHF_EXCLUDE.

The below email from Alan Modra to the binutils mailinglist is from
last month. By accident SHF_EXCLUDE was made a generic section flag
about 10 years ago in binutils, even though it technically is in the
processor specific section flag space.

I recently stumbled over SHF_EXCLUDE again because GCC uses it for
certain LTO sections (and has been doing this since at least 2010). And
clang uses it for "single-file-split-DWARF". All usages are apparently
as if SHF_EXCLUDE is a generic section flag.

glibc elf.h has defined SHF_EXCLUDE since 2003, apparently because
Solaris defined it. I cannot find when it was introduced in Solaris.
The Solaris documentation describes it as:

   SHF_EXCLUDE This section is excluded from input to the link-edit of
   an executable or shared object. This flag is ignored if the
   SHF_ALLOC flag is also set, or if relocations exist against the
   section.

It doesn't call out whether it is processor specific or not.
binutils ld and gold don't check whether the SHF_ALLOC flag is set or
if there are relocations against the section, but simply drop it
always.

What do people think we should do about SHF_EXCLUDE?

Since it has been in use for more than 10 years now it seems best to
just declare it as a generic section flag, but it really isn't because
it uses a constant in the processor specific section numbers...

On Tue, 2020-03-10 at 22:19 +1030, Alan Modra wrote:
> commit 18ae9cc1db made SHF_EXCLUDE generic.  Prior to that the flag
> was only defined for sparc, ppc, or32, and i370.  The problem is that
> the flag was left in the very limited SHF_MASKPROC processor specific
> range rather than being put in the generic range, and it clashes with
> other processor specific section flags.  aarch64, arm, hppa, mcore,
> microblaze, mips, mmix, nfp, score and v850 all define flags with the
> same value.  This means SHF_EXCLUDE as is really shouldn't be used on
> any of those machines.
> 
> aarch64.h:#define SHF_COMDEF		0x80000000
> arm.h:#define SHF_COMDEF         	0x80000000
> hppa.h:#define SHF_PARISC_SBP		0x80000000
> mcore.h:#define SHF_MCORE_NOREAD	0x80000000
> microblaze.h:#define SHF_MICROBLAZE_NOREAD	0x80000000
> mips.h:#define SHF_MIPS_STRING		0x80000000
> mmix.h:#define SHF_MMIX_CANRELAX	0x80000000
> nfp.h:#define SHF_NFP_INIT		0x80000000
> score.h:#define SHF_SCORE_STRING	0x80000000
> v850.h:#define SHF_RENESAS_ABS		0x80000000
> 
> SHF_PARISC_SBP, SHF_MCORE_NOREAD, SHF_MICROBLAZE_NOREAD,
> SHF_MIPS_STRING, SHF_MMIX_CANRELAX, SHF_SCORE_STRING, and
> SHF_RENESAS_ABS only appear in include/elf/*.h above.  I haven't
> searched any of the relevant ABI docs, if such exist.
> 
> SHF_COMDEF is decoded by readelf (once you disable SHF_EXCLUDE for
> arm
> and aarch64), but is described in arm docs by: "the legacy SHF_COMDEF
> ELF section flag is deprecated".
> 
> SHF_NFP_INIT is used in opcodes/nfp-dis.c but not set by
> bfd/elf64-nfp.c.
> 
> So what to do?  Disabling the flag and assembler support for 'e' in
> flags is one possibility, but not a good idea for a 10 year old
> feature.
>