public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Nick Clifton <nickc@redhat.com>
To: Peter Smith <peter.smith@linaro.org>,
	Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>,
	Sudakshina Das <Sudi.Das@arm.com>
Cc: "binutils@sourceware.org" <binutils@sourceware.org>,
	nd <nd@arm.com>, Richard Earnshaw <Richard.Earnshaw@arm.com>
Subject: Re: [PATCH, BFD, LD, AArch64, 0/4] Add support for AArch64 BTI and PAC in the linker
Date: Fri, 08 Mar 2019 12:32:00 -0000	[thread overview]
Message-ID: <0e91b77d-d13c-8487-0879-33f6bcf11d3e@redhat.com> (raw)
In-Reply-To: <CAEt-8LC6FP2-6_ac9X_kB=WiiWooa5XM622=3Gpkgf38T9oU_g@mail.gmail.com>

Hi Guys,

>> Given this conversation, maybe renaming --bti to --force-bti would
>> express the intention clearer ?

Yes - I rather like that idea.

> Indeed warnings can be ignored in most cases, particularly when there
> aren't too many. In a large project the output could be large enough
> to drown out other possibly more important warnings though.

Although I would suggest that warnings from the linker are a relatively
rare occurrence.  Unlike say a compiler ... :-)

In answer to Szabolcs's question:

> does -z ibt warn on x86_64?

No - it does not.  On the other hand, it does not force the enablement 
of ibt either.  In fact it appears to operate in the other way.  Linking
x86 binaries without specifying "-z ibt" or "-z ibtplt" on the command 
line will stop the linker from creating IBT enabled PLT entries, even if
all of the input object files would support them.


So - if we want to have the same behaviour in the AArch64 linker as we
currently have in the x86_64 linker, then how about this:

  * Without any specific command line options BTI and PAC are not
    enabled.  (Ie the dynamic tags are not added to the dynamic section).

  * With --bti specified, BTI is enabled in the output provided that
    the BTI note was found in all of the input files.  If one or more
    input files are missing the note, BTI is not enabled, no warnings
    are generated, *but* an entry is made in the linker map file indicating
    which object(s) caused BTI not to be enabled.  (Assuming that a
    linker map file is being generated).  This also matches the current
    behaviour of the x86_64 linker.

  * With --force-bti, BTI is enabled even if there are input files
    without the BTI note.  In this case, any file without the note
    triggers a warning message from the linker.

  * Similarly for PAC.  Ie --pac enables the PAC tag if all of the
    inputs support it, but no warnings are generated if some do not,
    and --force-pac always generates the PAC tag, but warns about
    object files that are missing the note.
    
What do people think ?

Cheers
  Nick

PS.  Sudi - the code for the patches themselves looks fine to me,
  so I have no concerns there.

  reply	other threads:[~2019-03-08 12:32 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
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 [this message]
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=0e91b77d-d13c-8487-0879-33f6bcf11d3e@redhat.com \
    --to=nickc@redhat.com \
    --cc=Ramana.Radhakrishnan@arm.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=Sudi.Das@arm.com \
    --cc=binutils@sourceware.org \
    --cc=nd@arm.com \
    --cc=peter.smith@linaro.org \
    /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).