From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14458 invoked by alias); 18 Feb 2020 12:49:37 -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 14227 invoked by uid 89); 18 Feb 2020 12:49:18 -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=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:a7078f7, H*i:sk:a7078f7 X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,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: mail-ot1-f65.google.com Received: from mail-ot1-f65.google.com (HELO mail-ot1-f65.google.com) (209.85.210.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 18 Feb 2020 12:48:50 +0000 Received: by mail-ot1-f65.google.com with SMTP id p8so19315205oth.10; Tue, 18 Feb 2020 04:48:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sJzvP+Mkq4Qd0fbWbltGTOj6itjMqPShq6qFH3fxAUE=; b=sjahsgDPqw2Q8xq8+MNKcIkyxfHLLShr0EXYT7/GupVHQJ3uhFtU5Q8RrtBwouG+DC eI48yzwdM6cWuWHll9HyJFtbo90P+R4+gVYWqzREXgax3HWgdy1kfERT5FzMsmvE0zTU t0oMoY+JQZtA+d4k/30TwsN4pX/e8aioXtt7zHl7fc1X+jLrQsWPWvw94mnjlsAqwBaX gq2W++CM0L7pBbPk4YAXxikH8u/rz1ELrlrYyuZ3xee0DjZCUTYilayIIpkxIes2mV9y rKM/bCgExJBOpHTpqXL66w3FMOVfzV82YHrffEZ4yLWREtLHOvRaX9GyqX+0nxIhI6rM i0QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sJzvP+Mkq4Qd0fbWbltGTOj6itjMqPShq6qFH3fxAUE=; b=ZIsbFR6J3gatOAH5VsDzlHRWXNm87n7Gba2U4DpPkvivCsIkmGmmXgW0KafTb9L/lq Q0BNv0iigj679VbyU0oxJECits2bHnR2ZpUwmS2gkiiU9zvXBILuVKqAUIKfwP9Y2zXH Igl/u3ckqVrHFzZEdXN97M27wAAF5+dIszjXB/FxVwJupQDjulEdsbURH4VZayAJlu6Y elhH+RrHAepyBg8vDnE6gGL1zRMFm4YnC6YbkdtSLtEZnNjGZG3Q+mA4UAB8ucZPQrSn uj27DxYUcf6/eYnwsJMC0RWExnOou14t8XdnL3lm07oS+R+jNcjQljRTGoX+66zEqXLZ TTyQ== X-Gm-Message-State: APjAAAUOARWmNlKwL6Tmsv4rc2zZJO+j0QjVlUfz5ESOM5PVobwWnUjn QqtT05qfM8C+v/WTQ9rgR4RVtn6+4A24fbeKU/g= X-Google-Smtp-Source: APXvYqxRmOg9DAmZTrWCOAbw5+lIrPaKmLZP3Az8iLONJzUoIA/hNI+kIpPV7QkfK/RzjkS/KS48RXR1ebykEN29Rg0= X-Received: by 2002:a9d:21c5:: with SMTP id s63mr3662467otb.142.1582030118041; Tue, 18 Feb 2020 04:48:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "H.J. Lu" Date: Wed, 01 Jan 2020 00:00:00 -0000 Message-ID: Subject: Re: binutils ld and new PT_GNU_PROPERTY segment To: Mark Wielaard Cc: Rahul Chaudhry via gnu-gabi , Binutils , "Zhang, Annita" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2020-q1/txt/msg00001.txt On Tue, Feb 18, 2020 at 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. -- H.J.