From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id F34A6385B835 for ; Thu, 16 Apr 2020 16:38:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F34A6385B835 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mark@klomp.org Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 9DF84302BB23; Thu, 16 Apr 2020 18:38:36 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 5C87F4028EB9; Thu, 16 Apr 2020 18:38:36 +0200 (CEST) Message-ID: <6b217d389fb1300f7e27be0712feb3ce222165e7.camel@klomp.org> Subject: Re: ELF section flag SHF_EXCLUDE From: Mark Wielaard To: binutils@sourceware.org Cc: generic-abi@googlegroups.com Date: Thu, 16 Apr 2020 18:38:36 +0200 In-Reply-To: <20200310114948.GW5384@bubble.grove.modra.org> References: <20200310114948.GW5384@bubble.grove.modra.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-8.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-10.3 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 16:38:39 -0000 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. >=20 > 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 >=20 > 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. >=20 > 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". >=20 > SHF_NFP_INIT is used in opcodes/nfp-dis.c but not set by > bfd/elf64-nfp.c. >=20 > 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. >=20