From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88914 invoked by alias); 18 Feb 2020 12:38:24 -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 88831 invoked by uid 89); 18 Feb 2020 12:38:23 -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; Tue, 18 Feb 2020 12:38:22 +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 4C8613001736; Tue, 18 Feb 2020 13:38:20 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 15A374B70B72; Tue, 18 Feb 2020 13:38:20 +0100 (CET) Message-ID: Subject: binutils ld and new PT_GNU_PROPERTY segment From: Mark Wielaard To: gnu-gabi@sourceware.org, binutils@sourceware.org Date: Wed, 01 Jan 2020 00:00:00 -0000 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/msg00000.txt 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. As far as I can tell binutils ld is the only linker which adds this 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. 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? Thanks, Mark