From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76807 invoked by alias); 19 Feb 2020 19:29:47 -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 76747 invoked by uid 89); 19 Feb 2020 19:29:46 -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:4BmqZ9E, H*f:hYan1h, H*f:CAMe9rOr7, sk:ch4.she 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-f67.google.com Received: from mail-ot1-f67.google.com (HELO mail-ot1-f67.google.com) (209.85.210.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Feb 2020 19:29:44 +0000 Received: by mail-ot1-f67.google.com with SMTP id w6so1315813otk.0; Wed, 19 Feb 2020 11:29:44 -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=GR0ucKPwxnpl7TWrWHQWcDHEj+SgpoKO3bm/lVX1ZQU=; b=HtDrl4lj6K8PXWAWwlUciykyX+5ajZGLDtAGrIE4/vDjVnTn9IpOd2JImadtOTLRrU 5qYutRzOjmZUs7/AtUXZA3xFuCNkaPwa8i5gcYS2+2sl0xnNhKPynC3ik4Nwi5j2+R/f oQnyRuQnVGWCsvBnwxpuqTGXws44tSeJJE0CpNBDf+onHkGb3JFzl7CufaWZT5M11pRv CEZuyyKVrNPOeulvx8n/UPFG92lJxgQ156CsKSAdxQK8jnp2FgRE0MYmHCRuo/uLqybj 3Ttoj6b9tjoxwLQxXKCjFXvOMWNZIUnhzU1NvkNk5WeP+o/++Ov6Uaa9ls8Sdy88lFul d/qQ== 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=GR0ucKPwxnpl7TWrWHQWcDHEj+SgpoKO3bm/lVX1ZQU=; b=GhGg7mcq7s+/1xOiBRxSEmbJ1hsOIlxHI779DWU35I+d3eH+3yicPnWtaRYo0qlMit ZeD5RMhIfBbkBMrN1JKC9sYqclMPdjWu60zHuM6Ju+NfBPfT9pUvy1Pb4ugWRU5aP6Lh +RcTnpiFLRGowrcfp00STDhPh76PWeREo0pa/iBB05FggczXUTx47RUrIUTP6mZ+bKeh nEikFTNrgARywnfmXpBSA7Gprqex7GAdy3Auo5JRGERKjUMm88xvh04qyrobLbLwPL1M IWvtAC8LiqB9nO02+8qd6c3y6TX4giNnC80Otanmw4WqO1hkyQZv4DyFEdEzeCdJtOqm mGlw== X-Gm-Message-State: APjAAAXKu89BwS9IV5v0EjRzTNR1gwcAwe6eGqiW3Rqf6E1qxZFiuxNf HFg7ejhDiy+xzA/0CmoL9sZ6Au0+74EgAHqoI1c= X-Google-Smtp-Source: APXvYqwFBrkQNlo54kFpncfmOyf5ZrnISaLUz0SKZCPPPlSXb++A7SwJkZWFp3/TynoJmEgK3Lzshc+n+IqbZKoBGc4= X-Received: by 2002:a9d:4c14:: with SMTP id l20mr20537077otf.125.1582140583279; Wed, 19 Feb 2020 11:29:43 -0800 (PST) MIME-Version: 1.0 References: <20200219023120.gvr4ajolbjbqcfix@google.com> <6bf04476b559f11965b4474b500156e26949ffc2.camel@klomp.org> <20200219182701.vrtzwhgtpelmpaub@google.com> In-Reply-To: <20200219182701.vrtzwhgtpelmpaub@google.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/msg00013.txt 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 wrote: > >> > > > 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 pat= ch > >> > > use the existing PT_NOTE segment? That would make it compatible wi= th > >> > > existing binaries that don't have this PT_GNU_PROPERTY program hea= der. > >> > > >> > Kernel loader is one of motivations of PT_GNU_PROPERTY. Kernel load= er > >> > 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 compli= cated 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 scheme = 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 apply = "Rules for Linking Unrecognized Sections" (http://www.sco.com/developers/ga= bi/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 this > scheme reaches consensus. It is kind of too late now. --=20 H.J.