From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116974 invoked by alias); 21 Feb 2020 03:00:51 -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 116862 invoked by uid 89); 21 Feb 2020 03:00:41 -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=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:rMb62mg, H*f:CAMe9rOpWbU, graceful, degradation X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,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: mail-oi1-f196.google.com Received: from mail-oi1-f196.google.com (HELO mail-oi1-f196.google.com) (209.85.167.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 21 Feb 2020 03:00:39 +0000 Received: by mail-oi1-f196.google.com with SMTP id z2so213498oih.6; Thu, 20 Feb 2020 19:00:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=iysUn/+gzbVHB8B7A1ajBtVc1onD0NPu4Umnqx23fB0=; b=bUrgqoqv/SUm5hNMnCpvDeAYQMroQB8rTRldRAECXqIc0rZmou9LZMfEf+06lR5gzj Fe8+R2d/DweGfveNHBP3TGwgQWQocRp6WhnfcTp9vBMl4SdhgZ6b0G3Bh8TJLb4XlkZK LfUxBui3A3ikuqG2HCv+msskiYCoG1EWuSr5Mv9HbcL7AryUrDA7bG/+RG7YWLbgZR1U 2zI5p53J/4peq3T+jAwFLf2OmnEwp4hB/DNYJDi56prdinDojjHkw9PQUzArY+tMmSxO X3gjXzy1/vljZ4fwRp0Ts3yitFBkkirDYIC765rIFCRtBfPlBS6OC7ZL7LoGc0E0uT9r HAOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=iysUn/+gzbVHB8B7A1ajBtVc1onD0NPu4Umnqx23fB0=; b=eSd+T5SCjiU1j7WXI7LmYB8k+gXi4L1c3rYIRldeK745DQpdSt7VmBC5vu9Y3/TW8a TsszAizVvAzE0cKCiQa7YroRjN19W2miy74bB97JcRQv5X20DMczoAOyQqqgMwFEilkE 3e4P2GY37eSIkXLLPpvSne/ZSW8DhTRO2dYfFoz8KXpAXctPx+8MD0aFEe1I+3QHZGND eoiHn7GxJh7Zg687W06Dn2JMbc6UMMlM2uFmeQ8ETA73u+Pa1KgHIYfOHVjRubcHnhNe pAbgkvV6HvzUbS8+UMxjuEwMp7WQPXBSXiZcCQI1ELEUU/1YadNvUARJQndmXSTLdV+D 3vOw== X-Gm-Message-State: APjAAAXaTgV8LjQzEVN6CVrSyVkkidAUOO2h22zaRAkBcAcRnP8nkDkq /F1eT+ikiOqMCSdw+O3O4JuCzC8Z8QcnOzwHyiY= X-Google-Smtp-Source: APXvYqxyfrwe8z14bOdDRkNxVSPLaxTM6lkd2xx84zbwghfEdfiPdmadKicWQZirzJ8CUrC/nB/EK2EuyJxG5uzJPm4= X-Received: by 2002:aca:43c1:: with SMTP id q184mr236534oia.116.1582254038041; Thu, 20 Feb 2020 19:00:38 -0800 (PST) MIME-Version: 1.0 References: <6bf04476b559f11965b4474b500156e26949ffc2.camel@klomp.org> <20200219182701.vrtzwhgtpelmpaub@google.com> <2e29243995903cf2d52975543675f2b92fa1e201.camel@klomp.org> <20200220214327.fg77jt2qnzfmh3d5@gmail.com> In-Reply-To: <20200220214327.fg77jt2qnzfmh3d5@gmail.com> From: "H.J. Lu" Date: Wed, 01 Jan 2020 00:00:00 -0000 Message-ID: Subject: Re: binutils ld and new PT_GNU_PROPERTY segment To: Fangrui Song Cc: Mark Wielaard , Cary Coutant , "Zhang, Annita" , "Liu, Hongtao" , gnu-gabi , Binutils Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2020-q1/txt/msg00020.txt On Thu, Feb 20, 2020 at 1:43 PM Fangrui Song wrote: > > On 2020-02-19, H.J. Lu wrote: > >On Wed, Feb 19, 2020 at 10:27 AM Fangrui Song wrote: > >> > >> On 2020-02-19, H.J. Lu wrote: > >> >On Wed, Feb 19, 2020 at 5:17 AM Mark Wielaard wrote: > >> >> > >> >> On Wed, 2020-02-19 at 04:28 -0800, H.J. Lu wrote: > >> >> > On Wed, Feb 19, 2020 at 4:02 AM Mark Wielaard wr= ote: > >> >> > > > https://patchwork.kernel.org/patch/11285409/ > >> >> > > > > >> >> > > > It is for both x86 and arm64. > >> >> > > > >> >> > > So that is not upstream in the mainline kernel? Why can't that = patch > >> >> > > use the existing PT_NOTE segment? That would make it compatible= with > >> >> > > existing binaries that don't have this PT_GNU_PROPERTY program = header. > >> >> > > >> >> > Kernel loader is one of motivations of PT_GNU_PROPERTY. Kernel l= oader > >> >> > only wants to check PT_XXX. > >> >> > >> >> So they can check PT_NOTE because it provides the same information = and > >> >> is already available in existing binaries. > >> >> > >> > > >> >Please take a look at glibc note.gnu.property parser. It is very com= plicated to > >> >check for invalid .note.gnu.property sections generated by the older > >> >linkers with > >> >the new object. Kernel loader doesn't want to do it. > >> > >> One way to make things follow the spirit of https://sourceware.org/ml/= gnu-gabi/2018-q4/msg00036.html > >> > >> * 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 > >> > >> The generated PT_NOTE will not include .note.gnu.property, so the sche= me 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) > >> > >> This way linkers can keep treating SHT_NOTE sections as opaque and app= ly "Rules for Linking Unrecognized Sections" (http://www.sco.com/developers= /gabi/latest/ch4.sheader.html ) when combining SHT_NOTE sections. At least = for lld, there will be no special rules for input SHT_NOTE sections. > >> > >> I will be happy to make changes to lld and LLVM binary utilities if th= is > >> scheme reaches consensus. > > > >It is kind of too late now. > > Better late than never. It is never late to fix the section type if we do= intend to fix it. > > Loaders don't read sections =3D> the section type change is backward comp= atible. > > On 2020-02-20, H.J. Lu wrote: > >On Thu, Feb 20, 2020 at 1:37 AM Mark Wielaard wrote: > >> > >> Hi, > >> > >> On Wed, 2020-02-19 at 14:17 -0800, H.J. Lu wrote: > >> > On Wed, Feb 19, 2020 at 1:46 PM Mark Wielaard wrote: > >> > > This code isn't in the kernel yet. So either it gets changed to us= e the > >> > > existing scheme with gnu property notes found through PT_NOTE to w= ork > >> > > 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. > >> > > >> > Binaries with .note.gnu.property section have been put into many > >> > OS releases. We must support them. > > We can teach newer assemblers to emit SHT_GNU_PROPERTY. > Newer linkers can support both SHT_GNU_PROPERTY/SHT_NOTE .note.gnu.proper= ty > > At some point in the future, linkers can drop support for SHT_NOTE .note.= gnu.property > Then it will become a graceful degradation: the old SHT_NOTE object files= will not be > different from older object files without .note.gnu.property > > >> 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. > >> > > > >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. > > The current PT_GNU_PROPERTY usage is all about hints. They are "nice to h= ave" but not > "necessary to have". I don't see any problem teaching newer loaders to fo= rget > PT_NOTE, if we do think PT_GNU_PROPERTY is the way forward. > > The currently mixed status is annoying: > > glibc: PT_NOTE > Proposed Linux kernel patch: PT_GNU_PROPERTY Since this has been deployed on Linux, any changes should be discussed at https://sourceware.org/ml/gnu-gabi/ --=20 H.J.