public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Peter Smith <peter.smith@linaro.org>
To: Sudakshina Das <Sudi.Das@arm.com>
Cc: "nickc@redhat.com" <nickc@redhat.com>,
	"binutils@sourceware.org" <binutils@sourceware.org>,
	nd <nd@arm.com>, 	Richard Earnshaw <Richard.Earnshaw@arm.com>,
		Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>
Subject: Re: [PATCH, BFD, LD, AArch64, 0/4] Add support for AArch64 BTI and PAC in the linker
Date: Thu, 07 Mar 2019 15:26:00 -0000	[thread overview]
Message-ID: <CAEt-8LCQzSBaO_haWpMBnXk3K5QFjhBSFhVUKV4OLqcL-V3Cbw@mail.gmail.com> (raw)
In-Reply-To: <c0f31807-6128-87a9-0b27-d10a30cf1df5@arm.com>

On Thu, 7 Mar 2019 at 14:28, Sudakshina Das <Sudi.Das@arm.com> wrote:
>
> Hi Nick
>
> On 07/03/2019 12:37, Nick Clifton wrote:
> > Hi Sudi,
> >
> >    [This is me being kind :-) ...]
>
> Thank you :)
> >
> >> We introduce a new set of command line options for the linker in order
> >> to support the correct PLTs
> >
> > Are you also planning on creating patches for GOLD and LLD to support
> > these features ?  If so, it would probably be best to submit them at
> > the same time as the BFD linker patches.
>
> I am CC'ing Peter who would be better able to answer about LLD and GOLD.

I've got LLD work on my backlog at the moment. It will likely need to
be coordinated with support for Intel CET
(https://reviews.llvm.org/D58102), which introduces .note.gnu.property
to LLD. Gold is of a lower priority right now, at least for Linaro,
with the most likely outcome that it will be worked on when a project
needs it, most likely when this feature is present in platforms that
people use gold to build applications with.

> > The document does not appear to specify what the loader should do if
> > there is more than one GNU_PROPERTY_AARCh64_FEATURE_1_AND note in an
> > executable.  (Which would be there if the executable had been linked
> > by a linker that does not know how to merge multiple GNU_PROPERTY notes).
> >
>
> Hmm I have not really considered that. I will get back to you soon on this.
>

My initial thought is that if there is more than one
.note.gnu.property section in the executable then the static linker
didn't understand the section and hence we can't assume it did any of
the required actions like producing different PLT sections. Hence I
think acting as if there were no .note.gnu.property sections present
at all would be a sensible choice.

Peter

  reply	other threads:[~2019-03-07 15:26 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-06 10:26 Sudakshina Das
2019-03-06 10:31 ` [PATCH, BFD, LD, AArch64, 1/4] Add support for GNU PROPERTIES in AArch64 for BTI and PAC Sudakshina Das
2019-03-06 10:34   ` [PATCH, BFD, LD, AArch64, 2/4] Add --bti-nowarn to enable BTI without warning and to select BTI enabled PLTs Sudakshina Das
2019-03-06 10:36     ` [PATCH, BFD, LD, AArch64, 3/4] Add --bti to enable BTI and select BTI enabled PLTs but also warn for missing NOTE sections Sudakshina Das
2019-03-06 10:39       ` [PATCH, BFD, LD, AArch64, 4/4] Add --pac-plt to enable PLTs protected with PAC Sudakshina Das
2019-04-11 14:47         ` Szabolcs Nagy
2019-03-07 12:37 ` [PATCH, BFD, LD, AArch64, 0/4] Add support for AArch64 BTI and PAC in the linker Nick Clifton
2019-03-07 14:28   ` Sudakshina Das
2019-03-07 15:26     ` Peter Smith [this message]
2019-03-07 15:35       ` Nick Clifton
2019-03-07 15:49         ` Szabolcs Nagy
2019-03-07 15:33     ` Nick Clifton
2019-03-07 17:53       ` Sudakshina Das
2019-03-08 10:07         ` Nick Clifton
2019-03-08 11:08           ` Szabolcs Nagy
2019-03-08 11:14           ` Ramana Radhakrishnan
2019-03-08 11:46             ` Peter Smith
2019-03-08 12:32               ` Nick Clifton
2019-03-08 12:44                 ` Ramana Radhakrishnan
2019-03-08 13:36                   ` Sudakshina Das
2019-03-11 12:30                     ` Nick Clifton
2019-03-13 11:49                       ` Sudakshina Das

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAEt-8LCQzSBaO_haWpMBnXk3K5QFjhBSFhVUKV4OLqcL-V3Cbw@mail.gmail.com \
    --to=peter.smith@linaro.org \
    --cc=Ramana.Radhakrishnan@arm.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=Sudi.Das@arm.com \
    --cc=binutils@sourceware.org \
    --cc=nd@arm.com \
    --cc=nickc@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).