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
