From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83641 invoked by alias); 19 Feb 2020 02:31:29 -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 83422 invoked by uid 89); 19 Feb 2020 02:31:28 -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=-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*r:sk:gnu-gab, H*i:sk:qO8uYLj, H*Ad:U*mark X-Spam-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 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: 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 j7so8912473plt.1 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== 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=SVnht/WZf9rMRmID9hJCL8zrRJBmt90aQkxUL6sNgJw=; b=peGsQ2rLzYI1uiJOcIhQcEanDf1y2OH03JqeCkwLODiu31vSkit8sXtVuH6YfXnKr4 TsnI1R8v7tY153US+G5dcdYuh9WBCtqhVavZvUXVav4OuAd+GwxKydhS/1BhlMmfxMtB 31q2Za/pD4eDBITVbWyx/dSLLkQLxKBtTD97gj5n551YWpcQWv7TPpsNNhrwF21aMBSv puEqtEdeVx09Lx//jgRN8WpzPQtWDjF2o+vM7eyWok4QFuyXGPkncMFjCElNrEh50F0H K8LlFmBOH1SBfremNpx0fS8HVATDvJOLGJHcKWzBZeEom9hNupC6RzdhdI28mdwuKMpu mBbg== X-Gm-Message-State: APjAAAXrEGu4jWhL95wzFJD+SQnfrKJyuHBRu7zLQzbN+/cxkml405Ra M1CIK2ZTJtFv9xmhaJdwOyeacg== X-Google-Smtp-Source: APXvYqwx/Rz0TsH9iVuvHS/lrn03KYPxoZO7GLMgTc2WKQ5ngtoWSEjatY60nIPuPGPSAQjwkqF9Mg== X-Received: by 2002:a17:90a:1b42:: with SMTP id q60mr6141205pjq.108.1582079484082; Tue, 18 Feb 2020 18:31:24 -0800 (PST) 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, 01 Jan 2020 00:00:00 -0000 From: "Fangrui Song via gnu-gabi" 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-q1/txt/msg00002.txt 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? :) )