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>,
	Peter Smith	<peter.smith@linaro.org>,
	Sudakshina Das <Sudi.Das@arm.com>
Cc: nd <nd@arm.com>,
	"binutils@sourceware.org" <binutils@sourceware.org>,
	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:49:00 -0000	[thread overview]
Message-ID: <b9008dff-9b46-c8c4-1263-817fef6b13f0@arm.com> (raw)
In-Reply-To: <2f8d7f31-cb87-4fba-dead-b131e355c619@redhat.com>

On 07/03/2019 15:35, Nick Clifton wrote:
>>>> 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).
> 
>> 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.
> 
> Agreed.  I would just like to see this clearly specified in the documentation
> so that other linker maintainers know where they stand.

so arm decided to use the "gnu property" thing to mark elf modules.
this means the behaviour should be mostly decided by "gnu" i think.

in this case if linkers don't merge gnu property notes, that sounds
like a processor independent problem so ideally the solution would
be the same across targets. (i.e. x86_64 and aarch64 should behave
consistently)

in any case this belongs to either an os specific sysv abi
document (i.e. linux-abi maintained by H.J.Lu) or processor
specific sys v abi (arm has not published this yet) because
those describe dynamic linking behaviour. (the arm elf abi
does not cover dynamic linking)


  reply	other threads:[~2019-03-07 15:49 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 [this message]
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=b9008dff-9b46-c8c4-1263-817fef6b13f0@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).