From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45896 invoked by alias); 10 May 2019 18:37:45 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 45888 invoked by uid 89); 10 May 2019 18:37:45 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=HTo:U*matz, recognized X-HELO: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 10 May 2019 18:37:43 +0000 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 359A230005AC; Fri, 10 May 2019 20:37:40 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id B592740350CB; Fri, 10 May 2019 20:37:40 +0200 (CEST) Message-ID: Subject: Re: GNU property saga From: Mark Wielaard To: Szabolcs Nagy , Michael Matz , "x86-64-abi@googlegroups.com" Cc: nd , "binutils@sourceware.org" Date: Fri, 10 May 2019 18:37:00 -0000 In-Reply-To: <25adbffa-fc4c-1b01-7949-fbe0dc212f70@arm.com> References: <25adbffa-fc4c-1b01-7949-fbe0dc212f70@arm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 X-SW-Source: 2019-05/txt/msg00167.txt.bz2 On Tue, 2019-05-07 at 15:29 +0000, Szabolcs Nagy wrote: > On 20/03/2019 14:51, Mark Wielaard wrote: > > As far as I understand the current consensus, for the existing property > > features, it is actually the opposite. There will be a new PT_NOTE > > segment with (for ELFCLASS64) larger alignment and padding. This is > > what the current glibc dynamic loader depends on. > >=20 > > But for the new GNU Property features it does seem that people would > > prefer to use a new PT_xxx value. There is a new constant in binutils: > > #define PT_GNU_PROPERTY (PT_LOOS + 0x474e553) /* GNU property */ > > But that isn't used anywhere else. > >=20 > > Question is, if we are going to use that for new GNU Property features, > > should we also do that for the old ones and how does that impact the > > existing binaries/dynamic libraries? >=20 > what is a "new gnu property feature"? The original GNU Properties were just for Control Flow Enforcement (STACK_SIZE, NO_COPY_ON_PROTECTED and X86_FEATUREs IBT and SHSTK). Those are in a special aligned SHT_NOTE section and PT_NOTE segment with adjusted padding. These are recognized by the glibc dynamic loader and some other tools. There are also some new experimental properties, the X86_ISA Needed and Used cpu instruction sets. For these new properties there doesn't seem to be any consensus. binutils and glibc define some of them with similar (but not always equal) GNU_PROPERTY names, but different constants. There is discussion how the used and needed bits should be interpreted (what if there is no such flag), see the other thread for a discussion of that. And binutils seems to put them in a new PT_GNU_PROPERTY segment which isn't recognized by anything else. > if PT_GNU_PROPERTY is preferred, then aarch64 should use that. > (aarch64 now uses gnu properties as well, but it does not have > legacy binaries yet to be compatible with, only code in bfd > that can be still fixed.) >=20 > but if current elf loaders/linkers only support PT_NOTE then > switching to PT_GNU_PROPERTY may be messy (?) Indeed. We first need consensus on all the issues above. > > > 1a) use new SHT_xxx for sections contain such properties > > >=20 > > > I believe the consensus was to stay with SHT_NOTE, even though that > > > is squarely against ELF spirit. > >=20 > > Yes, for the existing GNU Properties. But I think it would be a bad > > idea for the new property features if those will use a new PT value > > segment type. Then the rules for composing SHT_NOTEs become even more > > complex. You already need to distinguish between existing (GNU) notes > > which don't combine with the new (Property) notes because they use > > different alignment and padding rules. Then you would also get even > > different notes that don't combine with any of the existing ones. At > > least, the rules for combining them are not clear to me. >=20 > that tells me PT_NOTE and SHT_NOTE for gnu properties > should be left as they are today? Yes, I think it would be best to keep with that for the original (CET control flow related) GNU Properties. But maybe for new ISA/cpuset used/needed instruction set properties we should keep them separate and just start over and define a new SHT_GNU_PROPERTIES and PT_GNU_PROPERTIES format. Cheers, Mark