From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90138 invoked by alias); 19 Feb 2020 05:33:41 -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 90120 invoked by uid 89); 19 Feb 2020 05:33:40 -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=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_2 autolearn=ham version=3.3.1 spammy=HX-Languages-Length:3575, H*f:sk:qO8uYLj, H*Ad:U*mark X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_2 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: mga03.intel.com Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Feb 2020 05:33:38 +0000 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Feb 2020 21:33:37 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,459,1574150400"; d="scan'208";a="253984329" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by orsmga002.jf.intel.com with ESMTP; 18 Feb 2020 21:33:36 -0800 Received: from fmsmsx602.amr.corp.intel.com (10.18.126.82) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 18 Feb 2020 21:33:36 -0800 Received: from fmsmsx602.amr.corp.intel.com (10.18.126.82) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 18 Feb 2020 21:33:36 -0800 Received: from shsmsx107.ccr.corp.intel.com (10.239.4.96) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Tue, 18 Feb 2020 21:33:36 -0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.222]) by SHSMSX107.ccr.corp.intel.com ([169.254.9.46]) with mapi id 14.03.0439.000; Wed, 19 Feb 2020 13:33:34 +0800 From: "Zhang, Annita" To: Fangrui Song , "H.J. Lu" CC: Mark Wielaard , gnu-gabi , Binutils , "Liu, Hongtao" Subject: RE: binutils ld and new PT_GNU_PROPERTY segment Thread-Topic: binutils ld and new PT_GNU_PROPERTY segment Thread-Index: AQHV5lnDOup6UoVT2EeAiGUY+5Y2vaghRoYAgAC2/6A= Date: Wed, 01 Jan 2020 00:00:00 -0000 Message-ID: References: <20200219023120.gvr4ajolbjbqcfix@google.com> In-Reply-To: <20200219023120.gvr4ajolbjbqcfix@google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2020-q1/txt/msg00003.txt Regarding x86-64 ABI, we have internal communication if there's some update= . And we will raise it up in LLVM community if necessary.=20 Thanks, Annita -----Original Message----- From: Fangrui Song =20 Sent: Wednesday, February 19, 2020 10:31 AM To: H.J. Lu ; Zhang, Annita Cc: Mark Wielaard ; gnu-gabi ; Bin= utils Subject: Re: binutils ld and new PT_GNU_PROPERTY segment On 2020-02-18, H.J. Lu wrote: >On Tue, Feb 18, 2020@4:38 AM Mark Wielaard wrote: >> >> Hi, >> >> binutils 2.32 ld emits a new PT_GNU_PROPERTY (PT_LOOS + 0x474e553)=20 >> segment that overlaps with the PT_NOTE segment covering the=20 >> .note.gnu.property section data. >> >> I cannot tell if this is an accident/experiment that happened to end=20 >> up in a release or if it is proposed as an official new segment type. > >https://sourceware.org/ml/gnu-gabi/2018-q4/msg00027.html >https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI > >> As far as I can tell binutils ld is the only linker which adds this > >Annita, does lld generate PT_GNU_PROPERTY segment with CET? If not, it=20 >is an lld bug. > >> extra segment and there is no runtime loader which uses it. It=20 >> doesn't provide any new information that cannot be found in the=20 >> existing PT_NOTE segment. > >Kernel loader uses it for both ARM and x86. > >> On 64 bit architectures it simply covers the extra existing PT_NOTE=20 >> with 8 byte alignment (normal PT_NOTE segments are 4 byte aligned).=20 >> On 32bit architectures it covers a sub-range of the existing PT_NOTE=20 >> segment. >> >> It isn't clear to me how other tools should handle this. It seems to=20 >> prevent normal merging of note sections. Since some notes are=20 >> probably special if they need to be covered by this new segment type.=20 >> And it isn't clear how the linker knows which of the SHT_NOTE=20 >> sections is what needs to be covered by the new segment type. Or is=20 >> the idea that this will eventually come with a new section type too=20 >> and GNU properties will no longer use NOTE sections? >> > >PT_GNU_PROPERTY covers .note.gnu.property section. https://reviews.llvm.org/D70961 added PT_GNU_PROPERTY support to lld. The change will be included by lld 10.0.0 (currently at rc2). https://reviews.llvm.org/D70959 added the dump support to llvm-readelf -l a= nd llvm-objdump -p. The change will be included by LLVM 10.0.0 (currently at rc2). From what I can see, neither the Linux kernel nor glibc uses PT_GNU_PROPER= TY. glibc/sysdeps/x86/dl-prop.h parses PT_NOTE. I tend to agree with Cary (https://sourceware.org/ml/gnu-gabi/2018-q4/msg00036.html) that .note.gnu.p= roperty should have been designed as a different section type because its c= ombining semantics are different from other notes (we could apply "Rules fo= r Linking Unrecognized Sections" to all SHT_NOTE sections) but it is too la= te to change the section type. A separate segment type (PT_GNU_PROPERTY) looks fine to me. glibc should probably be updated to parse PT_GNU_PROPERTY instead. (Recently I read some ABI decisions and I noticed that I frequently see the= term "it is too late". As a contributor of both lld and LLVM binary utilit= ies (and the implementer of a bunch of GNU_PROPERTY changes), I hope that t= he LLVM community can be informed of such changes earlier. A lot of people= are not subscribed to any of the mailing lists (recently I visit the archi= ves from time to time). Looks like Annita's job? :) )