From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98193 invoked by alias); 20 Feb 2020 21:43:32 -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 98170 invoked by uid 89); 20 Feb 2020 21:43:32 -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:CAMe9rOpWbU, H*r:100, H*F:D*me, H*i:sk:rMb62mg 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-pf1-f194.google.com Received: from mail-pf1-f194.google.com (HELO mail-pf1-f194.google.com) (209.85.210.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 20 Feb 2020 21:43:30 +0000 Received: by mail-pf1-f194.google.com with SMTP id s1so27238pfh.10; Thu, 20 Feb 2020 13:43:30 -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=GT+b414RXj/f9ZdwII68G661+W17Fl+qwnY6d+lHTDM=; b=fyyMuQo5HE10dQ0x7pGUCh54ZDsSgYw26UHBxiPhnGbsCj4YUcbt60EqifJq23UTIH yvWj38HU++fnQS++BzSYk6DCXbsbzLnO005f48oZDseOvQ2aGbjrqDxL2AwBhMuScd85 0oSdNDYUeg5TJn0hy50zU03K04E1MKXSRn00Nc0OaBB0u1wCX9ubGQ+ng8B9TRt7SxK6 N8JpRdD8fPIZUtXzd6+/TvvFWHBBlIdsjBExlsHT6vlLrXMEwW8CwpPNxk0/CFfEomg6 BJE/vrppr8qrJwVyPr01FKM+gHjZYDVWj+Rnp6NO917iwTrzaLOYABk0KhczLFMiKHmN aaoA== X-Gm-Message-State: APjAAAXecuMj0t+48ZAlxExvV+NrdOGPynkToo3QDE5hdrKM/UbAypRX rmw5wBx/vFexUUP85Ac83bo= X-Google-Smtp-Source: APXvYqxckyp8pa8X/wJbuQS8lL22acO2K2UeAdCfW4wn5xwrHe4CIkhNLeHCC2bohKSuO9RH8g8Z5w== X-Received: by 2002:a63:6202:: with SMTP id w2mr29893657pgb.154.1582235008765; Thu, 20 Feb 2020 13:43:28 -0800 (PST) Received: from localhost ([2620:15c:2d1:100:5984:9ed:74e:4727]) by smtp.gmail.com with ESMTPSA id v7sm533109pfn.61.2020.02.20.13.43.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Feb 2020 13:43:27 -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: <20200220214327.fg77jt2qnzfmh3d5@gmail.com> References: <6bf04476b559f11965b4474b500156e26949ffc2.camel@klomp.org> <20200219182701.vrtzwhgtpelmpaub@google.com> <2e29243995903cf2d52975543675f2b92fa1e201.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/msg00018.txt 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 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. > >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 => the section type change is backward compatible. 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 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. We can teach newer assemblers to emit SHT_GNU_PROPERTY. Newer linkers can support both SHT_GNU_PROPERTY/SHT_NOTE .note.gnu.property 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 have" but not "necessary to have". I don't see any problem teaching newer loaders to forget 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