On Wed, Nov 2, 2016 at 10:52 AM, Jakub Jelinek <ja...@redhat.com> wrote: > On Wed, Nov 02, 2016 at 10:40:35AM +0100, Richard Biener wrote: >> > I wonder if the sanitize_asan_mark wouldn't better be some PROP_* property >> > set during the asan pass and kept on until end of compilation of that >> > function. That means even if a var only addressable because of ASAN_MARK >> > is >> > discovered after this pass we'd still be able to rewrite it into SSA. >> >> Note that being TREE_ADDRESSABLE also has effects on alias analysis >> (didn't follow the patches to see whether you handle ASAN_MARK specially >> in points-to analysis and/or alias analysis). >> >> Generally in update-address-taken you can handle ASAN_MARK similar to >> MEM_REF (and drop it in the rewrite phase?). > > That is the intent, but we can't do that before the asan pass, because > otherwise as Martin explained we don't diagnose at runtime bugs where > a variable is used outside of its scope only through a MEM_REF. > So we need to wait for asan pass to actually add a real builtin call that > takes the address in that case. Except now I really don't see how that > can work for the case where the var is used only properly when it is in the > scope, because the asan pass will still see those being addressable. > > Unless I'm missing something we either need to perform further analysis > during the addressable subpass - this variable could be made > non-addressable, but is used in ASAN_MARK, would if we rewrote it into SSA > form there be any SSA uses of the poisoning ASAN_MARK? If yes, keep it > addressable, otherwise rewrite into SSA. > Or, just rewrite it into SSA always, but turn the poisoning ASAN_MARK into > some new internal ECF_CONST call var_5 = ASAN_POISON (); and if we have any > uses of those, rewrite it back into addressable immediately or later or > something.
Or just give up optimizing (asan has a penalty anyway)? Or re-structure ASAN_POISON () similar to clobbers: var = ASAN_POISION (); that avoids the address-taking and thus should be less heavy-weight on optimizations. Richard. > > Jakub
