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.
next prev parent 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).