From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111092 invoked by alias); 20 Feb 2020 22:43:55 -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 111077 invoked by uid 89); 20 Feb 2020 22:43:54 -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=-5.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_BL_SPAMCOP_NET,SPF_PASS autolearn=no version=3.3.1 spammy=H*f:CAMe9rOpWbU, H*f:sk:rMb62mg, H*i:sk:rMb62mg, H*i:CAMe9rOpWbU X-Spam-Status: No, score=-5.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_BL_SPAMCOP_NET,SPF_PASS autolearn=no 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; Thu, 20 Feb 2020 22:43:53 +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 6FCAD300159E; Thu, 20 Feb 2020 23:43:49 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id A24F54B70B6F; Thu, 20 Feb 2020 23:43:49 +0100 (CET) Message-ID: Subject: Re: binutils ld and new PT_GNU_PROPERTY segment From: Mark Wielaard To: "H.J. Lu" Cc: Fangrui Song , 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> <2e29243995903cf2d52975543675f2b92fa1e201.camel@klomp.org> 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/msg00019.txt Hi, On Thu, 2020-02-20 at 03:51 -0800, H.J. Lu wrote: > On Thu, Feb 20, 2020 at 1:37 AM Mark Wielaard wrote: > > On Wed, 2020-02-19 at 14:17 -0800, H.J. Lu wrote: > > >=20 > > > Binaries with .note.gnu.property section have been put into many > > > OS releases. We must support them. > >=20 > > OK. Then it is option 1. The kernel will need to support PT_NOTE for > > parsing the properties, since such older binaries won't have a > > PT_GNU_PROPERTY program header. Then we can simply get rid of > > PT_GNU_PROPERTY since nobody uses it and all information is already > > available through the PT_NOTE segment. > >=20 >=20 > Kernel loader only checks ld.so and static executable. Re-link them with > newer linker will get PT_GNU_PROPERTY. But ld.so needs to check > PT_NOTE for older binaries. Having different loaders check different program headers seems very confusing. And it doesn't really seem to provide backwards compatibility since depending on how the code was linked previously you might still require a rebuild. Having a mix of PT_NOTE/PT_GNU_PROPERTY segments both based on SHT_NOTEs, but one of them based on magic section names, makes things really complicated for other tools. Please lets either really keep things as they are or redesign things based on PT_GNU_PROPERTY and a new section type. Thanks, Mark