This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PINGv5][PATCH] ASan on unaligned accesses
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Marat Zakirov <m dot zakirov at samsung dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Andrew Pinski <pinskia at gmail dot com>, Kostya Serebryany <kcc at google dot com>, Dmitry Vyukov <dvyukov at google dot com>, Yury Gribov <y dot gribov at samsung dot com>, Andrey Ryabinin <a dot ryabinin at samsung dot com>
- Date: Tue, 7 Apr 2015 14:22:02 +0200
- Subject: Re: [PINGv5][PATCH] ASan on unaligned accesses
- Authentication-results: sourceware.org; auth=none
- References: <54F6BBA0 dot 2010302 at samsung dot com> <CA+=Sn1k0yOKBr2Z1-S04VSsm097=hEzfMPJgZEgOsf7t4oj=+w at mail dot gmail dot com> <550A662E dot 3080308 at samsung dot com> <5513ACCF dot 7030502 at samsung dot com> <20150326115013 dot GY1746 at tucnak dot redhat dot com> <5513FB85 dot 4030305 at samsung dot com> <20150330174257 dot GJ1746 at tucnak dot redhat dot com> <5523AE6A dot 7010308 at samsung dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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