From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88074 invoked by alias); 19 Feb 2020 22:18:37 -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 88057 invoked by uid 89); 19 Feb 2020 22:18:37 -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*i:sk:2e29243, H*f:sk:2e29243 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-ot1-f68.google.com Received: from mail-ot1-f68.google.com (HELO mail-ot1-f68.google.com) (209.85.210.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Feb 2020 22:18:36 +0000 Received: by mail-ot1-f68.google.com with SMTP id j20so1774641otq.3; Wed, 19 Feb 2020 14:18:35 -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=w2GiFNDiNU6SGbtgRfinRiUjHwzy4HecC63eMDboTok=; b=UKPmOSoapGWW1AWRPiK5LyjqwpFbxgfLSFaHYgK68TGXn99kqZewiIjrLR63/fKhT1 xQYw7XkJMRh8qPVGFShDfbKahS03b6mRxILo5GFFyohb6LPYOl2Q0flgvcR3JVou3Bqr s7CgyyxKnHBZ4rKhI4h1WIedtyE7ZUfTy15gy3kD3ISKq3ww8VmX45OKH71hFMWn/O4x xtwCjVnHGu+XAAJBV9JZVZK5hMOUPMWL6vqoHmvIpWmrlbvy3EHkFNA9BfvH+42vAPJb fuAzzaP0xzlNcD5tYI9wU/BUPEgNv282PaUPmx4vQwpI0Aa5/zpdB2znUcE/G/BB8zex I7XA== 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=w2GiFNDiNU6SGbtgRfinRiUjHwzy4HecC63eMDboTok=; b=XTnTNF/QtMPHZQYNhLI84a6AAn6PPbiKOzXOf9mI2LK1+KnMVz5tKP9z7QizDgvZ82 6q0vFq8MfQl29iARMNvBuW26M/N2O/RyBUcpX3lUbZ4VZkI8cy0Q1PrfhiH86ebVCcdg KSgQy566M59OlsKYG0BZSpTFMzcMq7zcfVBjseCZMEgxk7AbNlcCR8BbNMX6hgrvhNpL pRPa5yNeV1QFqy3hCu/aws+lbMmgLPy7NzMljn86nUygRT5T/nHYAy14BPeNPUrVBY8N FMSJv2OxL3oG8rk5BxBiN9K+iy6xNMCCE74ZJlPF9NmE/eZ1kzFOwywn0CXcxgDl95wT XW8A== X-Gm-Message-State: APjAAAVmRqxhPZ5iSXQIcFurEWOxBUIl6lOSgFWfp4mpV1LatrNMITvQ ukNjFhm930aWd/TJHflkYdW3JkaQRVY/vwHUBaQ= X-Google-Smtp-Source: APXvYqzcpCEJFe0NadPwnf3UThIfE79DlcE0zqZsVwKiP/L/3oni72Yy/QKqkMHaAGC2w++PBjfPqZ8G2DkDLoK1BiQ= X-Received: by 2002:a9d:545:: with SMTP id 63mr21955231otw.285.1582150714390; Wed, 19 Feb 2020 14:18:34 -0800 (PST) MIME-Version: 1.0 References: <20200219023120.gvr4ajolbjbqcfix@google.com> <6bf04476b559f11965b4474b500156e26949ffc2.camel@klomp.org> <20200219182701.vrtzwhgtpelmpaub@google.com> <2e29243995903cf2d52975543675f2b92fa1e201.camel@klomp.org> In-Reply-To: <2e29243995903cf2d52975543675f2b92fa1e201.camel@klomp.org> 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: Mark Wielaard Cc: Fangrui Song , 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/msg00015.txt On Wed, Feb 19, 2020 at 1:46 PM Mark Wielaard wrote: > > 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= /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 sch= eme 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 ap= ply "Rules for Linking Unrecognized Sections" (http://www.sco.com/developer= s/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 t= his > > > scheme reaches consensus. > > > > 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. > Binaries with .note.gnu.property section have been put into many OS releases. We must support them. --=20 H.J.