public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
From: Will Newton <will.newton@linaro.org>
To: "Carlos O'Donell" <carlos@redhat.com>
Cc: "libc-ports@sourceware.org" <libc-ports@sourceware.org>,
	Patch Tracking <patches@linaro.org>
Subject: Re: [PATCH] ARM: Add pointer guard support.
Date: Wed, 25 Sep 2013 16:23:00 -0000	[thread overview]
Message-ID: <CANu=DmhCMr-LpHLaDRsLOHDVXsWm-sxHzRTMJxNCJs3Ae0uPZg@mail.gmail.com> (raw)
In-Reply-To: <52430AA4.70703@redhat.com>

On 25 September 2013 17:09, Carlos O'Donell <carlos@redhat.com> wrote:
> On 09/25/2013 05:06 AM, Will Newton wrote:
>>
>> Add support for pointer mangling in glibc internal structures in C
>> and assembler code.
>>
>> Tested on armv7 with hard and soft thread pointers.
>
> Have you measured the performance versus using the existing
> global variable?

No, but I'll put together a patch for that approach and see how it looks.

> TLS access on ARM is quite slow and it looks to me like it
> may be faster to use the global variable. Keep in mind that
> the pointer guard and stack guard do not vary by thread.

From a back of the envelope calculation the cost of accessing TLS is
one cycle faster than accessing a global in best case (e.g.
Cortex-A15), considerably slower in common case (50-60 cycles,
Cortex-A9) and slower still in worst case (function call to libgcc and
the kernel, ARMv4/ARMv5).

Pointer guard looks to be on slower code paths anyway as compared to
stack guard, but you may be right that the global variable solution is
the best way to go.

> 32-bit ARM is currently using a global variable e.g.
> __pointer_chk_guard, all you need to do to make it work
> is adjust the definitions of PTR_MANGLE and PTR_DEMANGLE
> to reference the global symbol.
>
> This is the second proposal for ARM (first was [1] for
> AArch64) to support storing the a guard in the TCB, but
> nobody has responded yet to my question about performance.

AArch64 the equation is different - all AArch64 cores have a TLS
register, and while it is not general purpose I suspect accessing it
will be much faster than on the worst performing 32bit cores. I don't
have any numbers though.

-- 
Will Newton
Toolchain Working Group, Linaro

  parent reply	other threads:[~2013-09-25 16:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-25  9:06 Will Newton
2013-09-25 16:09 ` Carlos O'Donell
2013-09-25 16:20   ` pinskia
2013-09-25 16:23   ` Will Newton [this message]
2013-09-25 16:25     ` Carlos O'Donell
2013-09-25 16:59     ` Andrew Haley
2013-09-25 19:32       ` Will Newton
2013-09-26 15:02 ` Carlos O'Donell

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='CANu=DmhCMr-LpHLaDRsLOHDVXsWm-sxHzRTMJxNCJs3Ae0uPZg@mail.gmail.com' \
    --to=will.newton@linaro.org \
    --cc=carlos@redhat.com \
    --cc=libc-ports@sourceware.org \
    --cc=patches@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).