From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83652 invoked by alias); 19 Feb 2020 02:31:29 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 83425 invoked by uid 89); 19 Feb 2020 02:31:28 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.1 required=5.0 tests=BAYES_00,ENV_AND_HDR_SPF_MATCH,FSL_HELO_FAKE,RCVD_IN_DNSWL_NONE,SPF_PASS,USER_IN_DEF_SPF_WL autolearn=no version=3.3.1 spammy=subscribed, H*Ad:U*mark, H*i:sk:qO8uYLj, H*f:sk:qO8uYLj X-HELO: mail-pl1-f195.google.com Received: from mail-pl1-f195.google.com (HELO mail-pl1-f195.google.com) (209.85.214.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Feb 2020 02:31:26 +0000 Received: by mail-pl1-f195.google.com with SMTP id p11so8891824plq.10 for ; Tue, 18 Feb 2020 18:31:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=SVnht/WZf9rMRmID9hJCL8zrRJBmt90aQkxUL6sNgJw=; b=RheJL+dxhwqQN/JB8msNKW7j+0NVNLDIGSOLfOYuB7PubsbSqv2gT6GIcQayjzHwUG O+4zBr8AyEqcCaaMCG9XlfktC+pdHMQ2hhUXhpK7pFxUO3LKlaAAgyoPyCkIlL59+R9i Bzb5GjY6/pwwxmsevfUG3+Mt0sg3vqH3SFjGFP00uaCy8IzSFPUG25Yg80f6WRkc4yU/ +z3P3AkEyqKjrkFsICEa0+iFrrIE2sr1fj9vBQOpDfs9vN6FHaiPTErKk2CedLtO+SWZ Ygyo2XRWvV9q5PqDnYyIa/Hcusr4Rz0Zn5MU9FHeOaFULlzpTmwv+FqBeCpH+NWUyHpV AMzQ== Return-Path: Received: from google.com ([2620:15c:2ce:0:9efe:9f1:9267:2b27]) by smtp.gmail.com with ESMTPSA id x21sm333473pfn.164.2020.02.18.18.31.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Feb 2020 18:31:23 -0800 (PST) Date: Wed, 19 Feb 2020 02:31:00 -0000 From: "Fangrui Song via binutils" Reply-To: Fangrui Song To: "H.J. Lu" , "Zhang, Annita" Cc: Mark Wielaard , gnu-gabi , Binutils Subject: Re: binutils ld and new PT_GNU_PROPERTY segment Message-ID: <20200219023120.gvr4ajolbjbqcfix@google.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-SW-Source: 2020-02/txt/msg00432.txt.bz2 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) >> segment that overlaps with the PT_NOTE segment covering the >> .note.gnu.property section data. >> >> I cannot tell if this is an accident/experiment that happened to end 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 is an lld bug. > >> extra segment and there is no runtime loader which uses it. It doesn't >> provide any new information that cannot be found in the 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 >> with 8 byte alignment (normal PT_NOTE segments are 4 byte aligned). On >> 32bit architectures it covers a sub-range of the existing PT_NOTE >> segment. >> >> It isn't clear to me how other tools should handle this. It seems to >> prevent normal merging of note sections. Since some notes are probably >> special if they need to be covered by this new segment type. And it >> isn't clear how the linker knows which of the SHT_NOTE sections is what >> needs to be covered by the new segment type. Or is the idea that this >> will eventually come with a new section type too 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 and 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_PROPERTY. 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.property should have been designed as a different section type because its combining semantics are different from other notes (we could apply "Rules for Linking Unrecognized Sections" to all SHT_NOTE sections) but it is too late 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 utilities (and the implementer of a bunch of GNU_PROPERTY changes), I hope that the 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 archives from time to time). Looks like Annita's job? :) )