https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81040
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |NEW
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The problem is that on the stack we just instrument the user variables (those
seen in expand_used_vars). But that is not the case of addressable arguments,
those aren't known to need some stack slot until later, in particular the
pass_expand::execute method after expand_used_vars calls expand_function_start
and that calls assign_parms -> assign_parm_setup_stack -> assign_stack_local.
Now, some addressable arguments that are passed on the stack actually are using
the argument passing slot where you can't insert any red zones around, it is
part of ABI how arguments are passed, but in other cases (e.g. if the argument
is not passed on the stack but e.g. in registers, or partially in
registers/partially on the stack, or fully on the stack, but with smaller
guaranteed alignment) the compiler copies those arguments from those spots to
other stack slots and those slots could be in theory using red zones.
It is hard though, because for other vars we are conditionally using asan
allocation instead of stack slots (decided at runtime).
So, in order to instrument addressable arguments, we'd need to guess in
expand_used_vars for which arguments we'll need an asan protected slot
(PARM_DECLs that are TREE_ADDRESSABLE, but their types aren't TREE_ADDRESSABLE)
and include those into the allocations and remember it somewhere (not sure if
DECL_RTL on PARM_DECL is suitable for it or not), and then later on arrange for
those slots to be what is used instead of assign_stack_local.
And then there is another problem, because while the asan allocation/shadow
initialization sequence is created earlier (expand_used_vars), it is actually
emitted later (after the copying of the parameters into stack slots if
necessary). That order has a good reason, e.g. __asan_stack_malloc_* function
is a normal function call, so clobbers registers used for argument passing.
So perhaps in some worst cases we'd need to copy the arguments into a temporary
slot and then again copy them into the asan red zone protected one.
