From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19641 invoked by alias); 19 Feb 2020 10:58:27 -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 19618 invoked by uid 89); 19 Feb 2020 10:58:26 -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.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy= X-Spam-Status: No, score=-6.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS 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: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Feb 2020 10:58:25 +0000 Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 2CB47300B37B; Wed, 19 Feb 2020 11:58:22 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 159924015E8A; Wed, 19 Feb 2020 11:58:22 +0100 (CET) Message-ID: Subject: Re: binutils ld and new PT_GNU_PROPERTY segment From: Mark Wielaard To: Fangrui Song , "H.J. Lu" , "Zhang, Annita" Cc: gnu-gabi , Binutils Date: Wed, 01 Jan 2020 00:00:00 -0000 In-Reply-To: <20200219023120.gvr4ajolbjbqcfix@google.com> References: <20200219023120.gvr4ajolbjbqcfix@google.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-5.el7) Mime-Version: 1.0 X-Spam-Flag: NO X-SW-Source: 2020-q1/txt/msg00005.txt Hi, On Tue, 2020-02-18 at 18:31 -0800, Fangrui Song wrote: > From what I can see, neither the Linux kernel nor glibc uses > PT_GNU_PROPERTY. > glibc/sysdeps/x86/dl-prop.h parses PT_NOTE. That is my impression too. > 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. Agreed. > A separate segment type (PT_GNU_PROPERTY) looks fine to me. > glibc should probably be updated to parse PT_GNU_PROPERTY instead. I think it is confusing to now introduce a new segment type which basically provides the same information as the PT_NOTE segement. It is ill defined because it needs to be matched to a magic section name. Which makes things harder for tools dealing with generic SHT_NOTE sections (they would have to preserve the magic section name, might not be able to merge notes, etc.) > (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). Yeah, we really need to do a better job coordinating and communicating. Even though I am trying to keep up with these lists I am often surprised by changes like this which seem to have just been added to binutils without trying to get consensus with other GNU/ELF tool implementations about the precise semantics or whether a feature is simply redundant with existing practice. Cheers, Mark