On Tue, Oct 16, 2012 at 2:52 PM, Jakub Jelinek <ja...@redhat.com> wrote: > On Tue, Oct 16, 2012 at 01:56:46PM -0700, Xinliang David Li wrote: >> Looks good except for the following: >> >> 1) I am not sure if the stack slot sharing is handled correctly. If I >> read the code correctly, the redzone var will be only created for the >> representative variable in a partition -- will this lead to false >> negatives? As I asked before, should stack slot sharing even turned >> on? > > I thought we don't merge stack slots if the vars have different size, > apparently I've been wrong about that. So I'll make sure those aren't > shared with flag_asan. When the size is the same, there should be no false > negatives. > >> 2) Performance tuning -- it is probably better to skip those variables >> that are compiler generated -- is there any point guarding them? > > In my (admittedly very limited) testing only at -O0 some compiler generated > vars (SSA_NAMEs) got guards. The trouble here is -fasan -fstack-protector > combination. I wonder if there can be any DECL_ARTIFICIAL (or non-VAR_DECL/ > RESULT_DECL) decls for which stack_protect_decl_phase returns 1 or 2. > If it is unlikely, the best might be to protect all phase 1 and 2 vars and > if flag_asan call expand_stack_vars once more for partitions where any of > the protected vars are user vars, and finally the current expand_stack_vars > (NULL) which would not do any asan protection. >
Do we expect people to use -fasan together with -fstack-protector? Is it enough to just skip those DECL_ARTIFICIAL ones? most of the ssa_name var decls are already skipped already. David > Jakub
