From patchwork Mon Dec 3 18:18:56 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Konstantin Serebryany X-Patchwork-Id: 203410 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 435292C007B for ; Tue, 4 Dec 2012 05:19:32 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1355163573; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: MIME-Version:Received:In-Reply-To:References:From:Date: Message-ID:Subject:To:Cc:Content-Type:Mailing-List:Precedence: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=8v2VjRWZSMahdbrAWu+dkfgXLkY=; b=u9JJbjxBr1HhiSC N2HEpBZmiPI9Q+6WfH+VoA1b0J9Anxzowyf+eSj20fm6Ir6eU0D+N2VHx1+tzAyb ul+ylie+mdo6rWhK8V84E2v6lWE8aEIUSawXH3aBgQFnN8/+/h4qSzxoxqGJvA2Z FhHgLHcCQ4QtzrT/pMKVCekFgClg= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:MIME-Version:Received:In-Reply-To:References:From:Date:Message-ID:Subject:To:Cc:Content-Type:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=RwH/IZVK0a4b4pnL2A9XnQjJtL6tbynr3eQxk8hXGKD0c8vdN7/khNjt1/aWaT M+tAG3KknDVLIq8iSHuEpx+q2GH1NVDFn5tHMpiMMOO1zUKhQ2iyD7yZz7jnqt9x 0Y7b0qZ2mnLPbTOzx/2LFXETYs02MwPYv00crQRqT8gsg=; Received: (qmail 15474 invoked by alias); 3 Dec 2012 18:19:27 -0000 Received: (qmail 15462 invoked by uid 22791); 3 Dec 2012 18:19:26 -0000 X-SWARE-Spam-Status: No, hits=-5.4 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, KHOP_RCVD_TRUST, KHOP_THREADED, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE, TW_KC X-Spam-Check-By: sourceware.org Received: from mail-la0-f47.google.com (HELO mail-la0-f47.google.com) (209.85.215.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 03 Dec 2012 18:19:18 +0000 Received: by mail-la0-f47.google.com with SMTP id u2so2430710lag.20 for ; Mon, 03 Dec 2012 10:19:16 -0800 (PST) Received: by 10.112.46.37 with SMTP id s5mr4669555lbm.67.1354558756706; Mon, 03 Dec 2012 10:19:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.135.105 with HTTP; Mon, 3 Dec 2012 10:18:56 -0800 (PST) In-Reply-To: <20121203.130249.270151183416121233.davem@davemloft.net> References: <20121121.114044.1913869006160026705.davem@davemloft.net> <20121203.130249.270151183416121233.davem@davemloft.net> From: Konstantin Serebryany Date: Mon, 3 Dec 2012 22:18:56 +0400 Message-ID: Subject: Re: Sparc ASAN To: David Miller Cc: bergner@vnet.ibm.com, gcc-patches@gcc.gnu.org, ebotcazou@adacore.com, dje.gcc@gmail.com, wmi@google.com, dvyukov@google.com X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org On Mon, Dec 3, 2012 at 10:02 PM, David Miller wrote: > From: Konstantin Serebryany > Date: Tue, 27 Nov 2012 18:12:00 +0400 > >> On Wed, Nov 21, 2012 at 9:05 PM, Konstantin Serebryany >> wrote: >>> On Wed, Nov 21, 2012 at 8:40 PM, David Miller wrote: >>>> From: Konstantin Serebryany >>>> Date: Wed, 21 Nov 2012 19:39:52 +0400 >>>> >>>>> There are various other things that asan library does not support. >>>> >>>> I'm trying to understand why making the page size variable >>>> is such a difficult endeavour. >>> >>> Maybe it's not *that* difficult. >>> Looking at it carefully, the major problem I can see is that some >>> other constants are defined based on this one. >>> Give me a few days to resolve it... >>> http://code.google.com/p/address-sanitizer/issues/detail?id=128 >> >> http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193849 removes the >> kPageSize constant in favor of a function call. >> Please give it a try. >> >> BTW, libsanitizer now has a usable process to quickly pull the upstream changes. >> It should make it easier for us to iterate on platform-specific patches. > > So, with the hacks for unaligned accesses, Sparc seems to be working > here. > > The only changes to libsantizier is to put __sparc__ checks where > __powerpc__ checks exist in the unwind code. Like this? > > Are there any clear thoughts about what we should do in the end > wrt. the stack ASAN alignment issues? Do we plan to 32-byte > align the stack variables or similar? Otherwise we need to add > some ugly code to do half-word/byte at a time accesses, as needed. The LLVM implementation always used 32-byte alignment for stack redzones. I never actually did any performance checking on x86 (32-byte aligned vs 8-byte aligned), although I suspect 32-byte aligned redzones should be ~2x faster. 8-byte aligned redzones trade some CPU for some stack memory and probably slightly increase the chances of catching large (33+ bytes off) buffer overflows. For strict alignment architectures 8-byte aligned redzones is obviously not a choice. We either need to align the redzones by 32 always, or for some platforms. Either is fine for me. --kcc =================================================================== --- asan/asan_linux.cc (revision 169136) +++ asan/asan_linux.cc (working copy) @@ -158,7 +158,9 @@ stack->trace[0] = pc; if ((max_s) > 1) { stack->max_size = max_s; -#if defined(__arm__) || defined(__powerpc__) || defined(__powerpc64__) +#if defined(__arm__) || \ + defined(__powerpc__) || defined(__powerpc64__) || \ + defined(__sparc__) _Unwind_Backtrace(Unwind_Trace, stack); // Pop off the two ASAN functions from the backtrace. stack->PopStackFrames(2);