From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <binutils-return-109083-listarch-binutils=sources.redhat.com@sourceware.org>
Received: (qmail 67156 invoked by alias); 19 Feb 2020 13:17:03 -0000
Mailing-List: contact binutils-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <binutils.sourceware.org>
List-Subscribe: <mailto:binutils-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/binutils/>
List-Post: <mailto:binutils@sourceware.org>
List-Help: <mailto:binutils-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: binutils-owner@sourceware.org
Received: (qmail 67133 invoked by uid 89); 19 Feb 2020 13:17:03 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-6.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=H*MI:sk:6bf0447
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 13:17:01 +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 3400D300047E;	Wed, 19 Feb 2020 14:16:59 +0100 (CET)
Received: by tarox.wildebeest.org (Postfix, from userid 1000)	id E67D34015E8A; Wed, 19 Feb 2020 14:16:58 +0100 (CET)
Message-ID: <df471f18bee6c4dcdb40c284aac719524f1ad148.camel@klomp.org>
Subject: Re: binutils ld and new PT_GNU_PROPERTY segment
From: Mark Wielaard <mark@klomp.org>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Fangrui Song <maskray@google.com>, "Zhang, Annita" <annita.zhang@intel.com>,  gnu-gabi <gnu-gabi@sourceware.org>, Binutils <binutils@sourceware.org>
Date: Wed, 19 Feb 2020 13:17:00 -0000
In-Reply-To: <CAMe9rOpgwi0M9XqbeyUm+LLuqypObZBmEGEAgFAyDeUYck5ucA@mail.gmail.com>
References: <a7078f74881daf23ca4af4983bac212a6c971b5a.camel@klomp.org>	 <CAMe9rOqCJVw2okDr0gonHWpxEVw+qO8uYLjbzxihB4tx-JuJ6g@mail.gmail.com>	 <20200219023120.gvr4ajolbjbqcfix@google.com>	 <dadc7c7f28171eae1fe537d0be4fa4fbdaf4eaab.camel@klomp.org>	 <CAMe9rOozPmwbp30x2sEmkdR1MJ4bdT1j0-TvWsyNU-nfSj_WKA@mail.gmail.com>	 <6bf04476b559f11965b4474b500156e26949ffc2.camel@klomp.org>	 <CAMe9rOpgwi0M9XqbeyUm+LLuqypObZBmEGEAgFAyDeUYck5ucA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0
X-IsSubscribed: yes
X-SW-Source: 2020-02/txt/msg00462.txt.bz2

On Wed, 2020-02-19 at 04:28 -0800, H.J. Lu wrote:
> On Wed, Feb 19, 2020 at 4:02 AM Mark Wielaard <mark@klomp.org> wrote:
> > > https://patchwork.kernel.org/patch/11285409/
> > >=20
> > > It is for both x86 and arm64.
> >=20
> > So that is not upstream in the mainline kernel? Why can't that patch
> > use the existing PT_NOTE segment? That would make it compatible with
> > existing binaries that don't have this PT_GNU_PROPERTY program header.
>=20
> Kernel loader is one of motivations of PT_GNU_PROPERTY.  Kernel loader
> only wants to check PT_XXX.

So they can check PT_NOTE because it provides the same information and
is already available in existing binaries.

Cheers,

Mark