From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130473 invoked by alias); 19 Feb 2020 10:49:43 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 130412 invoked by uid 89); 19 Feb 2020 10:49:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:qO8uYLj X-Spam-Status: No, score=-6.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-Spam-User: qpsmtpd, 2 recipients 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; Wed, 19 Feb 2020 10:49:40 +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 EF279300B37B; Wed, 19 Feb 2020 11:49:36 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id A2A984015E8A; Wed, 19 Feb 2020 11:49:36 +0100 (CET) Message-ID: <4a2518534d4b3b1ac66cad20251588df00969741.camel@klomp.org> Subject: Re: binutils ld and new PT_GNU_PROPERTY segment From: Mark Wielaard To: "H.J. Lu" Cc: Rahul Chaudhry via gnu-gabi , Binutils , "Zhang, Annita" Date: Wed, 01 Jan 2020 00:00:00 -0000 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-5.el7) Mime-Version: 1.0 X-Spam-Flag: NO X-SW-Source: 2020-q1/txt/msg00004.txt Hi, On Tue, 2020-02-18 at 04:48 -0800, H.J. Lu wrote: > On Tue, Feb 18, 2020 at 4:38 AM Mark Wielaard wrote: > > binutils 2.32 ld emits a new PT_GNU_PROPERTY (PT_LOOS + 0x474e553) > > segment that overlaps with the PT_NOTE segment covering the > > .note.gnu.property section data. > >=20 > > I cannot tell if this is an accident/experiment that happened to > > end up > > in a release or if it is proposed as an official new segment type. >=20 > https://sourceware.org/ml/gnu-gabi/2018-q4/msg00027.html > https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI I see you added it, but I don't see consensus for it. It also doesn't really make sense if it still uses the same section type and has to rely on a magic section name. > > As far as I can tell binutils ld is the only linker which adds this >=20 > Annita, does lld generate PT_GNU_PROPERTY segment with CET? If not, > it is an lld bug. I think it is the other way around, binutils ld generates it, but nobody uses it, it is redundant and the interaction with other tools dealing with SHT_NOTE sections isn't really clear. > > extra segment and there is no runtime loader which uses it. It > > doesn't > > provide any new information that cannot be found in the existing > > PT_NOTE segment. >=20 > Kernel loader uses it for both ARM and x86. I cannot find it. Could you point to where it uses it? Why doesn't it simply use the PT_NOTE segment? > > On 64 bit architectures it simply covers the extra existing PT_NOTE > > with 8 byte alignment (normal PT_NOTE segments are 4 byte aligned). On > > 32bit architectures it covers a sub-range of the existing PT_NOTE > > segment. > >=20 > > It isn't clear to me how other tools should handle this. It seems to > > prevent normal merging of note sections. Since some notes are probably > > special if they need to be covered by this new segment type. And it > > isn't clear how the linker knows which of the SHT_NOTE sections is what > > needs to be covered by the new segment type. Or is the idea that this > > will eventually come with a new section type too and GNU properties > > will no longer use NOTE sections? > >=20 >=20 > PT_GNU_PROPERTY covers .note.gnu.property section. Using magic section names is a problem. It means other tools can no longer rely on the section type. Can we please simply remove this because it isn't used, doesn't provide any new information, depends on magic section names and makes it harder for other tools to deal with generic SHT_NOTE sections. Thanks, Mark