From: Fangrui Song <i@maskray.me>
To: Alan Modra <amodra@gmail.com>
Cc: binutils@sourceware.org
Subject: Re: ELF section flag SHF_EXCLUDE
Date: Wed, 11 Mar 2020 17:41:34 -0700 [thread overview]
Message-ID: <20200312004134.o5bjmpfv3txnf5r5@google.com> (raw)
In-Reply-To: <20200310114948.GW5384@bubble.grove.modra.org>
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.
next prev parent reply other threads:[~2020-03-12 0:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-10 11:49 Alan Modra
2020-03-12 0:41 ` Fangrui Song [this message]
2020-03-12 2:05 ` Alan Modra
2020-03-15 22:31 ` Hans-Peter Nilsson
2020-04-16 16:38 ` Mark Wielaard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200312004134.o5bjmpfv3txnf5r5@google.com \
--to=i@maskray.me \
--cc=amodra@gmail.com \
--cc=binutils@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).