* ELF section flag SHF_EXCLUDE
@ 2020-03-10 11:49 Alan Modra
2020-03-12 0:41 ` Fangrui Song
2020-04-16 16:38 ` Mark Wielaard
0 siblings, 2 replies; 5+ messages in thread
From: Alan Modra @ 2020-03-10 11:49 UTC (permalink / raw)
To: binutils
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.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ELF section flag SHF_EXCLUDE
2020-03-10 11:49 ELF section flag SHF_EXCLUDE Alan Modra
@ 2020-03-12 0:41 ` Fangrui Song
2020-03-12 2:05 ` Alan Modra
2020-04-16 16:38 ` Mark Wielaard
1 sibling, 1 reply; 5+ messages in thread
From: Fangrui Song @ 2020-03-12 0:41 UTC (permalink / raw)
To: Alan Modra; +Cc: binutils
On 2020-03-10, 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.
Recent reference of the unfortunate fact:
https://sourceware.org/pipermail/binutils/2020-February/109567.html [PATCH] Support 'exclude' in objcopy --set-section-flags
>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.
Arm Compiler 6.11 deprecates the following features:
Support for ELF sections that contain the legacy SHF_COMDEF ELF section flag has been deprecated
binutils does not use SHF_COMDEF.
LLVM does not have SHF_COMDEF at all.
We can probably recycle SHF_COMDEF for arm/aarch64.
Is SHF_MIPS_STRING in the same camp?
clang -gsplit-dwarf=single emits .debug_*.dwo in the object file and sets the SHF_EXCLUDE flag (https://reviews.llvm.org/D52303).
SHF_EXCLUDE is more useful than the probably obsoleted processor specific flags.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ELF section flag SHF_EXCLUDE
2020-03-12 0:41 ` Fangrui Song
@ 2020-03-12 2:05 ` Alan Modra
2020-03-15 22:31 ` Hans-Peter Nilsson
0 siblings, 1 reply; 5+ messages in thread
From: Alan Modra @ 2020-03-12 2:05 UTC (permalink / raw)
To: Fangrui Song; +Cc: binutils
On Wed, Mar 11, 2020 at 05:41:34PM -0700, Fangrui Song wrote:
> On 2020-03-10, 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.
>
> Recent reference of the unfortunate fact:
> https://sourceware.org/pipermail/binutils/2020-February/109567.html [PATCH] Support 'exclude' in objcopy --set-section-flags
>
> > 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.
>
> Arm Compiler 6.11 deprecates the following features:
>
> Support for ELF sections that contain the legacy SHF_COMDEF ELF section flag has been deprecated
>
> binutils does not use SHF_COMDEF.
> LLVM does not have SHF_COMDEF at all.
>
>
> We can probably recycle SHF_COMDEF for arm/aarch64.
>
> Is SHF_MIPS_STRING in the same camp?
I'd say so. It was likely superceded by SHF_STRINGS.
>
> clang -gsplit-dwarf=single emits .debug_*.dwo in the object file and sets the SHF_EXCLUDE flag (https://reviews.llvm.org/D52303).
> SHF_EXCLUDE is more useful than the probably obsoleted processor specific flags.
Yes, I'm not about to remove SHF_EXCLUDE for those targets where there
is a clash.
Ideally the flag should be moved to the generic SHF space, for example
#define SHF_EXCLUDE (1 << 12)
keeping support for the existing flag for some time.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ELF section flag SHF_EXCLUDE
2020-03-12 2:05 ` Alan Modra
@ 2020-03-15 22:31 ` Hans-Peter Nilsson
0 siblings, 0 replies; 5+ messages in thread
From: Hans-Peter Nilsson @ 2020-03-15 22:31 UTC (permalink / raw)
To: Alan Modra; +Cc: Fangrui Song, binutils
On Thu, 12 Mar 2020, Alan Modra via Binutils wrote:
> Yes, I'm not about to remove SHF_EXCLUDE for those targets where there
> is a clash.
>
> Ideally the flag should be moved to the generic SHF space, for example
> #define SHF_EXCLUDE (1 << 12)
> keeping support for the existing flag for some time.
Please. Stealing processor specific flags and bullying by
calling them obsolete is not TRT.
brgds, H-P
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ELF section flag SHF_EXCLUDE
2020-03-10 11:49 ELF section flag SHF_EXCLUDE Alan Modra
2020-03-12 0:41 ` Fangrui Song
@ 2020-04-16 16:38 ` Mark Wielaard
1 sibling, 0 replies; 5+ messages in thread
From: Mark Wielaard @ 2020-04-16 16:38 UTC (permalink / raw)
To: binutils; +Cc: generic-abi
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.
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-04-16 16:38 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-10 11:49 ELF section flag SHF_EXCLUDE Alan Modra
2020-03-12 0:41 ` Fangrui Song
2020-03-12 2:05 ` Alan Modra
2020-03-15 22:31 ` Hans-Peter Nilsson
2020-04-16 16:38 ` Mark Wielaard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).