From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102986 invoked by alias); 7 Apr 2015 12:22:11 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 102974 invoked by uid 89); 7 Apr 2015 12:22:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 07 Apr 2015 12:22:09 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t37CM88S009193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 7 Apr 2015 08:22:08 -0400 Received: from tucnak.zalov.cz (ovpn-116-58.ams2.redhat.com [10.36.116.58]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t37CM6o9016241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 7 Apr 2015 08:22:08 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id t37CM5jJ025303; Tue, 7 Apr 2015 14:22:05 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id t37CM3Gx025281; Tue, 7 Apr 2015 14:22:03 +0200 Date: Tue, 07 Apr 2015 12:22:00 -0000 From: Jakub Jelinek To: Marat Zakirov Cc: "gcc-patches@gcc.gnu.org" , Andrew Pinski , Kostya Serebryany , Dmitry Vyukov , Yury Gribov , Andrey Ryabinin Subject: Re: [PINGv5][PATCH] ASan on unaligned accesses Message-ID: <20150407122202.GD19273@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <54F6BBA0.2010302@samsung.com> <550A662E.3080308@samsung.com> <5513ACCF.7030502@samsung.com> <20150326115013.GY1746@tucnak.redhat.com> <5513FB85.4030305@samsung.com> <20150330174257.GJ1746@tucnak.redhat.com> <5523AE6A.7010308@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5523AE6A.7010308@samsung.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00232.txt.bz2 On Tue, Apr 07, 2015 at 01:16:10PM +0300, Marat Zakirov wrote: > On 03/30/2015 08:42 PM, Jakub Jelinek wrote: > >Can you please start by explaining the asan_emit_stack_protection changes? > >What is the problem there, what do you want to achieve etc.? Is it to > >support ABI violating stack pointer alignment, or something different? If > >so, the compiler knows (or should be aware) what the stack alignment is. > >The asan_expand_check_ifn change looks reasonable. > This patch is needed to support ASan on codes (like Linux kernel) which do > not care about compiler stack alignment - see example from the attached > patch: That is not sufficient description to me. > long long *ptr; > > __attribute__((noinline)) > void foo () { > ptr = ((long long int *)(((char *)ptr) + 1)); > *ptr = 1; > } > > int main () > { > long long int local[9]; > ptr = (long long *)&local[8]; > foo (); > return 0; > } This testcase has, at least when compiled with say -O2 -fsanitize=address, local array aligned, so I don't understand why would you need any special changes in the prologue and/or epilogue of functions for that, the asan_expand_check_ifn of course makes sense. How are the automatic misaligned variables different from say heap allocated ones, or global vars etc.? So can you explain the rationale for the prologue/epilogue changes and what you are trying to do with that? Is kernel using some non-standard option like -mincoming-stack-boundary= etc.? If so, perhaps you should make the changes dependent on that? > Fixed in new patch. But I believe joining movs (2 movl to one movq) is a > x86 RTL job - not ASan. Well, a RTL solution I've tried at http://gcc.gnu.org/PR22141, but it gave mixed results, so either it needs more cost tuning when it is desirable and when it is not, or perhaps better do that still on GIMPLE instead, together with trying to optimize bitfield accesses and other cases of adjacent location accesses. But if we handle that on GIMPLE, it won't really affect what asan RTL emitting code produces. Jakub