[asan] Protection of stack vars (take 2)
Xinliang David Li
davidxl@google.com
Tue Oct 16 23:02:00 GMT 2012
On Tue, Oct 16, 2012 at 2:52 PM, Jakub Jelinek <jakub@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
More information about the Gcc-patches
mailing list