This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug sanitizer/81040] asan false negative if parameter of a global function passed by reference
- From: "marxin at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 13 Jun 2017 12:27:21 +0000
- Subject: [Bug sanitizer/81040] asan false negative if parameter of a global function passed by reference
- Auto-submitted: auto-generated
- References: <bug-81040-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81040
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
--- Comment #11 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #10)
> (In reply to Martin Liška from comment #9)
> > Thanks Jakub for your thoughts. I was also thinking about simple approach
> > similar to what we do for use-after-scope in situations where there's a
> > usage of IFN_ASAN_POISON. In that case we generate a 'shadow' variable
> > that's poison/unpoisoned, etc. We can come up with automatic variables to
> > which we assign an addressable PARM_DECL and then these variables will be
> > normally protected with red zones. I can imaging bigger performance gap, but
> > it can be quite easily doable I guess?
>
> That would work too. If doing it this way, it would be desirable to do it
> late in the GIMPLE pass queue, e.g. in the sanopt pass, for the
> TREE_ADDRESSABLE PARM_DECLs that don't have TREE_ADDRESSABLE types (those
> are passed by invisible reference) create the DECL_ARTIFICIAL VAR_DECLs,
> have them TREE_ADDRESSABLE, add
> code to copy the PARM_DECLs to those vars at the beginning of the function,
> clear TREE_ADDRESSABLE on the PARM_DECLs and remap all uses of the
> PARM_DECLs except the newly added ones to the new VAR_DECLs. Not sure if
> the PARM_DECLs should have DECL_VALUE_EXPR pointing to the VAR_DECLs (e.g.
> for debug info purposes), and whether the artificial VAR_DECLs should be
> added to some BLOCK_VARS or not.
Good. I will implement that in this stage1 ;)