From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) by sourceware.org (Postfix) with ESMTPS id DED42395C869 for ; Thu, 12 Mar 2020 02:05:44 +0000 (GMT) Received: by mail-pf1-x441.google.com with SMTP id b72so2404130pfb.11 for ; Wed, 11 Mar 2020 19:05:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=+mQ2lny8GfIcvsunrhbUaKbfBMuzhcMEFdhRSwEnWg8=; b=Dq5XZ+C6AJhM/zweL1tXWIWMsDfJXEYGoUg8z5qccVPGH9LNzM1DdARj9AIuSybcQe K5GwrLnlyPWQ7GV0S/rVHtQMeffFIcM73hQkAR1tqz3MksSVavtpF9NIOCLbiDcUAnCJ rBGc5SE4HyyJ6w78+RQb6cqybIHvDbxeiPAdFH+AQakTh47Nj6awUoFYIZ2ZJAoJPrQg 7+yUTDrFNwHx6FQK6NmioXuq/N8Bc+9r15NQFrdPu8Q3HFUXQPDvXxsZO0CrBxxVpy8i HBr2qU9MLQBJw4SGbmcl6JI8eKhUXVw0AgVefcVo+sDxBnQTvdS6VN4j4DeL6cvI05Jo DnFg== X-Gm-Message-State: ANhLgQ1Lr5Ri+dE0Malhno852VNWkaZfaYT79rxbmijR0HYV5M45ZRoM yy2aDv7m38I4oIoJ2VdtymjQen6dkU8= X-Google-Smtp-Source: ADFU+vttLyxmx4RJ5bcMemg2rkAQLqutXI4xpMU4yJkTde+IZz6Ylxg3kHIXa/pUPgEMFQShfXkViw== X-Received: by 2002:a62:6490:: with SMTP id y138mr5624711pfb.96.1583978743918; Wed, 11 Mar 2020 19:05:43 -0700 (PDT) Received: from bubble.grove.modra.org (158.106.96.58.static.exetel.com.au. [58.96.106.158]) by smtp.gmail.com with ESMTPSA id l1sm3450968pje.9.2020.03.11.19.05.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Mar 2020 19:05:43 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 6089981DCC; Thu, 12 Mar 2020 12:35:39 +1030 (ACDT) Date: Thu, 12 Mar 2020 12:35:39 +1030 From: Alan Modra To: Fangrui Song Cc: binutils@sourceware.org Subject: Re: ELF section flag SHF_EXCLUDE Message-ID: <20200312020539.GD5384@bubble.grove.modra.org> References: <20200310114948.GW5384@bubble.grove.modra.org> <20200312004134.o5bjmpfv3txnf5r5@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200312004134.o5bjmpfv3txnf5r5@google.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS autolearn=ham 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, 12 Mar 2020 02:05:46 -0000 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