Hello,
On Mon, 17 Jul 2017, Martin Liška wrote:
> which does all the stack preparation (including the problematic call to
> __asan_stack_malloc_N).
>
> Note that this code still should be placed before parm_birth_note as we
> cant's say that params are ready before a fake stack is prepared.
Yes, understood.
> Then we generate code that loads the implicit chain argument:
>
> (gdb) p debug_rtx_list(get_insns(), 100)
> (note 1 0 37 NOTE_INSN_DELETED)
>
> (note 37 1 38 NOTE_INSN_FUNCTION_BEG)
>
> (insn 38 37 39 (set (reg/f:DI 94 [ CHAIN.1 ])
> (reg:DI 39 r10 [ CHAIN.1 ]))
> "/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/asan/pr81186.c":9 -1
> (nil))
>
> (insn 39 38 0 (set (mem/c:DI (plus:DI (reg/f:DI 82 virtual-stack-vars)
> (const_int -584 [0xfffffffffffffdb8])) [0 S8 A64])
> (reg:DI 39 r10 [ CHAIN.1 ]))
> "/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/asan/pr81186.c":9 -1
> (nil))
>
> Which is problematic as using virtual-stack-vars which should point to
> fake stack done by AddressSanitizer in __asan_stack_malloc_N.
If anything, then only the stack access is problematic, i.e. the last
instruction. I don't understand why that should be problematic, though.
Probably because I don't know much about the ASAN implementation. But why
should there be something magic about using the non-asan stack? Most
local variable accesses are rewritten to be in terms of the fake stack,
but those that aren't could use the normal stack just fine, can't they?
If that really is a problem then that could also be rectified by splitting
the static_chain_decl in expand_function_start a bit, ala this:
if (cfun->static_chain_decl) {
all code except the last "if (!optimize) store-into-stack"
}
emit_note; parm_birth_insn = ...
if (cfun->static_chain_decl && !optimize) {
store into assign_stack_local
}
(requires moving some local variable to an outer scope, but hey).
But what you say above mystifies me. You claim that access via
virtual-stack-vars is problematic before the shadow stack is created by
ASAN. But the whole parameter setup always uses such local stack storage
whenever it needs. And those definitely happen before the ASAN setup.
See the subroutines of assign_parms, (e.g. assign_parm_setup_block and
assign_parm_setup_stack). You might need to use special function argument
types or special ABIs to trigger this, though you should be able to find
some cases to trigger also on i386 or x86_64.
So, if the stack access for the static chain is problematic I don't see
why the stack accesses for the parameters are not. And if they indeed are
problematic, then something is confused within ASAN, and the fix for that
confusion is not to move parm_birth_insn, but something else (I can't say
what, as I don't know much about how ASAN is supposed to work in such
situations).
Ciao,
Michael.
