public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To: libc-alpha@sourceware.org
Subject: Re: [PATCH] aarch64: MTE compatible strchrnul
Date: Wed, 3 Jun 2020 11:33:18 -0300	[thread overview]
Message-ID: <04f67459-9c4e-da69-0323-c3d535cedc68@linaro.org> (raw)
In-Reply-To: <87img8uszs.fsf@oldenburg2.str.redhat.com>



On 03/06/2020 11:24, Florian Weimer via Libc-alpha wrote:
> * Andrea Corallo:
> 
>> Florian Weimer <fweimer@redhat.com> writes:
>>
>>> * Andrea Corallo:
>>>
>>>> Introduce an Arm MTE compatible strchrnul implementation.
>>>>
>>>> Benchmarked on Cortex-A72, Cortex-A53, Neoverse N1 does not show
>>>> performance regressions.
>>>>
>>>> Co-authored-by: Wilco Dijkstra <wilco.dijkstra@arm.com>
>>>
>>> As a very high-level comment, I would expect some sort of markup in the
>>> file that this implementation is now MTE-safe, similar to what we have
>>> for executable stacks.
>>>
>>> Or do you plan to handle that in some other fashion?
>>>
>>> Thanks,
>>> Florian
>>
>> Hi Florian,
>>
>> Now the only markup is the comment on the top of the file stating the
>> MTE compatibility of the routine.
>>
>> I'm not aware of how this marking is done for executable stacks, perhaps
>> could you give an hook on where to look for?
> 
> Typically, the -z noexecstack flag or a special .note.GNU-stack section
> is used for that.
> 
>> Just to make sure we are one the same page wanted to add: these
>> functions are supposed to be backward compatible with what they are
>> replacing, so I'm not sure a marking is necessary.
> 
> It's MTE that isn't backwards-compatible without such markup.

Afaiu there is no need to add any marking for MTE, the main difference
it enforce 16-byte granularity read. I think you are confusing with
BTI, which does require the GNU note.


  reply	other threads:[~2020-06-03 14:33 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-03  9:43 Andrea Corallo
2020-06-03 11:27 ` Florian Weimer
2020-06-03 14:14   ` Andrea Corallo
2020-06-03 14:24     ` Florian Weimer
2020-06-03 14:33       ` Adhemerval Zanella [this message]
2020-06-03 14:53         ` Szabolcs Nagy
2020-06-03 15:03           ` Szabolcs Nagy
2020-06-03 15:04           ` Adhemerval Zanella
2020-06-03 15:04         ` Florian Weimer
2020-06-03 15:18           ` Szabolcs Nagy
2020-06-03 15:24             ` Florian Weimer
2020-06-03 14:40 ` Adhemerval Zanella
2020-06-03 16:01   ` Andrea Corallo
2020-06-04 12:04     ` H.J. Lu
2020-06-04 19:48       ` Szabolcs Nagy
2020-06-04 20:03         ` H.J. Lu
2020-06-05  7:38           ` Szabolcs Nagy
2020-06-05  8:45             ` Wilco Dijkstra
2020-06-05 16:25               ` Szabolcs Nagy

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=04f67459-9c4e-da69-0323-c3d535cedc68@linaro.org \
    --to=adhemerval.zanella@linaro.org \
    --cc=libc-alpha@sourceware.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).