public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Szabolcs Nagy <Szabolcs.Nagy@arm.com>
To: "nickc@redhat.com" <nickc@redhat.com>,
	Sudakshina Das <Sudi.Das@arm.com>,
	"binutils@sourceware.org" <binutils@sourceware.org>
Cc: nd <nd@arm.com>, Richard Earnshaw <Richard.Earnshaw@arm.com>,
	Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>,
	"peter.smith@linaro.org"	<peter.smith@linaro.org>
Subject: Re: [PATCH, BFD, LD, AArch64, 0/4] Add support for AArch64 BTI and PAC in the linker
Date: Fri, 08 Mar 2019 11:08:00 -0000	[thread overview]
Message-ID: <7d597e5d-bf26-1948-c353-3e55c4eeaa98@arm.com> (raw)
In-Reply-To: <054d9601-0009-2227-3155-1c013beb74dd@redhat.com>

On 08/03/2019 10:07, Nick Clifton wrote:
> Hi Sudi,
> 
>>> OK, so just to be clear, with --bti or --bti-nowarn the output will be
>>> given the BTI tag *even if* some of the input files do not have the BTI note ?
> 
>> Yes
> 
>> can go back and check the objects that need recompiling or use 
>> --bti-nowarn when they are sure that even if there is any object with 
>> missing BTI note section it is still safe to turn on BTI (or they still 
>> want to turn on BTI). We think that these options would be most helpful 
>> in early deployment.
> 
> OK, well I get the --bti option then, but I still think that --bti-nowarn
> is a mistake.  Given that --bti will only generate warnings if there are
> object files without the BTI note, and warnings can be ignored, I do not
> see the need for --bti-nowarn.  Plus using --bti-nowarn could potentially
> cause problems if the developer forgets (or does not know) that it is 
> enabled, and they end up thinking that they are creating BTI enabled 
> binaries when in fact they are not.
> 
> If a developer really wants to skip the warnings they could pipe the
> output from the linker through a grep that eliminates them.  Which would
> have the added benefit of being more visible in the output logs of a 
> complex build than a single command line option.

does -z ibt warn on x86_64?

it is important to allow the user to force bti on
(a non-bti marked object file can easily be compatible
with bti, e.g if there are no indirect branches targeting
it, or somebody might just want to do runtime tests to
find out where are the problematic branches), so at least
one of --bti or --bti-nowarn should be added, it is just
convenience to have them both since there are different
use cases.

i think it's also reasonable to just have one option that
is compatible with the x86_64 behaviour.


  reply	other threads:[~2019-03-08 11:08 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 [this message]
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=7d597e5d-bf26-1948-c353-3e55c4eeaa98@arm.com \
    --to=szabolcs.nagy@arm.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=nickc@redhat.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).