From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31452 invoked by alias); 19 Feb 2020 18:27:06 -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 31432 invoked by uid 89); 19 Feb 2020 18:27:06 -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=-1.1 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KAM_INFOUSMEBIZ,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy=H*f:sk:4BmqZ9E, H*i:sk:4BmqZ9E, H*i:hYan1h, H*f:hYan1h X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KAM_INFOUSMEBIZ,KAM_SHORT,RCVD_IN_DNSWL_NONE,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: mail-pg1-f193.google.com Received: from mail-pg1-f193.google.com (HELO mail-pg1-f193.google.com) (209.85.215.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Feb 2020 18:27:05 +0000 Received: by mail-pg1-f193.google.com with SMTP id v23so519989pgk.2; Wed, 19 Feb 2020 10:27:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=9TGL55gEnfB/hU26lMhJ+sShGXHc9YUkJ88OfmUS9/M=; b=OwQOo4GWtse1phK2lBT3xak+BlQxijDCVqwP12oEhuAgRkhXl2kzVGTGijwAtiAe6Z yi/ySp+JOS1oDoKHY7RJ0Su7SFoEYJkf7tRArH3ZdpCBZYqwRYvVb8BhXTGgEj2quAl9 BOxq/9G8oON1FGTe/Dl8Rzh7GxFMqh0pXcueOr0lp5//3ht0FAk9EYg67OWqwDmOqbka 2GWMV5mRlXU/pWUc1rEsd/bkpfXh5C/hedsWPN2XRIm4Ib1LiTiIWQOazMNIuDhYQTOJ 6IYHcbsQsiPhlwEC44Iu92Y/AG+FGvxHgkICnX5xMLadQLy76DvU3MCRq2g0EAWFvdbZ 9iPg== X-Gm-Message-State: APjAAAW8QliNie2qa1vtPiZdvSZWoHdHt7c7XIa6on5WqfYoovaW+/Hm zT150eNblvW2nxHUBmap4Xg= X-Google-Smtp-Source: APXvYqyyikMPMkUS/vn+qOIkTdP4r3pWY6z8V3V16W8Tw9+C7Asgmaa7KfR5wF12Tn4NwAlPjPEFgA== X-Received: by 2002:a63:ec0c:: with SMTP id j12mr28090102pgh.78.1582136823528; Wed, 19 Feb 2020 10:27:03 -0800 (PST) Received: from localhost ([2620:15c:2d1:100:5984:9ed:74e:4727]) by smtp.gmail.com with ESMTPSA id i2sm484576pjs.21.2020.02.19.10.27.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Feb 2020 10:27:02 -0800 (PST) Date: Wed, 01 Jan 2020 00:00:00 -0000 From: Fangrui Song To: "H.J. Lu" Cc: Mark Wielaard , Cary Coutant , "Zhang, Annita" , "Liu, Hongtao" , gnu-gabi , Binutils Subject: Re: binutils ld and new PT_GNU_PROPERTY segment Message-ID: <20200219182701.vrtzwhgtpelmpaub@google.com> References: <20200219023120.gvr4ajolbjbqcfix@google.com> <6bf04476b559f11965b4474b500156e26949ffc2.camel@klomp.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-SW-Source: 2020-q1/txt/msg00012.txt 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 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 loader >> > 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 complicated 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/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 this scheme reaches consensus.