From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38678 invoked by alias); 19 Feb 2020 21:46:54 -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 38661 invoked by uid 89); 19 Feb 2020 21:46:53 -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.2 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,SPF_PASS autolearn=ham version=3.3.1 spammy=H*MI:sk:df471f1, H*i:sk:g@mail., H*MI:sk:g@mail. X-Spam-Status: No, score=-6.2 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,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 21:46:52 +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 B9DE6300047E; Wed, 19 Feb 2020 22:46:48 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 69B9F406BB87; Wed, 19 Feb 2020 22:46:48 +0100 (CET) Message-ID: <2e29243995903cf2d52975543675f2b92fa1e201.camel@klomp.org> Subject: Re: binutils ld and new PT_GNU_PROPERTY segment From: Mark Wielaard To: "H.J. Lu" , Fangrui Song Cc: Cary Coutant , "Zhang, Annita" , "Liu, Hongtao" , gnu-gabi , Binutils Date: Wed, 01 Jan 2020 00:00:00 -0000 In-Reply-To: References: <20200219023120.gvr4ajolbjbqcfix@google.com> <6bf04476b559f11965b4474b500156e26949ffc2.camel@klomp.org> <20200219182701.vrtzwhgtpelmpaub@google.com> 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/msg00014.txt Hi, On Wed, 2020-02-19 at 11:29 -0800, H.J. Lu wrote: > On Wed, Feb 19, 2020 at 10:27 AM Fangrui Song wrote: > > One way to make things follow the spirit of https://sourceware.org/ml/g= nu-gabi/2018-q4/msg00036.html > >=20 > > * Define SHT_GNU_PROPERTY > > * Set sh_type(.note.gnu.property) to SHT_GNU_PROPERTY > > * Place SHT_GNU_PROPERTY sections in a PT_GNU_PROPERTY segment > >=20 > > The generated PT_NOTE will not include .note.gnu.property, so the schem= e is compatible with old loaders (ld.so, gdb, Linux, etc). > > New loaders should interpret PT_GNU_PROPERTY, instead of PT_NOTE. > > ( https://patchwork.kernel.org/patch/11285409/ needs no change) > >=20 > > This way linkers can keep treating SHT_NOTE sections as opaque and appl= y "Rules for Linking Unrecognized Sections" (http://www.sco.com/developers/= gabi/latest/ch4.sheader.html ) when combining SHT_NOTE sections. At least f= or lld, there will be no special rules for input SHT_NOTE sections. > >=20 > > I will be happy to make changes to lld and LLVM binary utilities if this > > scheme reaches consensus. >=20 > It is kind of too late now. This code isn't in the kernel yet. So either it gets changed to use the existing scheme with gnu property notes found through PT_NOTE to work with existing binaries. Then there is no need for PT_GNU_PROPERTY headers. Or some future kernel will start using PT_GNU_PROPERTY headers to find the gnu property notes. But that means it won't work with existing binaries that do not have that header. So there is no backwards compatibility anyway and we can define SHT_GNU_PROPERTY like above. So this actually seems the perfect time to make this decision. Cheers, Mark