From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2460 invoked by alias); 25 Sep 2013 16:23:46 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 2450 invoked by uid 89); 25 Sep 2013 16:23:45 -0000 Received: from mail-ie0-f175.google.com (HELO mail-ie0-f175.google.com) (209.85.223.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 25 Sep 2013 16:23:45 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.3.2 X-HELO: mail-ie0-f175.google.com Received: by mail-ie0-f175.google.com with SMTP id e14so10914240iej.20 for ; Wed, 25 Sep 2013 09:23:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DELelkBMrc2x8jy4oKEfwxXZ7XI+VMGoyeXShnMTtGM=; b=JWPKJq2qcOySVp7B1gEJbV2kvTGKZf7iwn0dxg7pQ8PMGdZnH/OMZ2e4dCgUwchq1/ vQ4i4se5UsLOsjOS30mNLMqrZkruZM6Avp/WphGef/zdtn9GSHTBN4Ia4qiV8dZM6xLK O8LItBt1K8IUl6fEdvEwlyFkPTwDVu9ta6vjTGwC1FxTd6mis7EHyNYPwT9tyHvLDeYU 5nCuMmY+jzOOkuAzKglNmHbmJWQtsTf47Ew59K+bG+qXJoYAqhM1DtNdJGVxCmUB7+hi 0ic2cskusEY2HTtsJTw2yCs6Z6EDIGDwJ+YQGrC3ALypm9/kcIg5uRT1PdZkBUzz7+R0 vs4g== X-Gm-Message-State: ALoCoQn/XMHHOIFnMkoSWbISaoWeEYQE8pQINgUApvRhy7is/xe1mPGsTYIyruoSi3FgLjguKvY+ MIME-Version: 1.0 X-Received: by 10.42.76.196 with SMTP id f4mr1786845ick.99.1380126223394; Wed, 25 Sep 2013 09:23:43 -0700 (PDT) Received: by 10.64.20.52 with HTTP; Wed, 25 Sep 2013 09:23:43 -0700 (PDT) In-Reply-To: <52430AA4.70703@redhat.com> References: <5242A79D.1030709@linaro.org> <52430AA4.70703@redhat.com> Date: Wed, 25 Sep 2013 16:23:00 -0000 Message-ID: Subject: Re: [PATCH] ARM: Add pointer guard support. From: Will Newton To: "Carlos O'Donell" Cc: "libc-ports@sourceware.org" , Patch Tracking Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-09/txt/msg00134.txt.bz2 On 25 September 2013 17:09, Carlos O'Donell 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