On Thu, Dec 8, 2016 at 1:51 PM, Martin Liška <mli...@suse.cz> wrote: > On 12/02/2016 01:29 PM, Richard Biener wrote: >> On Thu, Dec 1, 2016 at 5:30 PM, Martin Liška <mli...@suse.cz> wrote: >>> On 11/23/2016 03:13 PM, Jakub Jelinek wrote: >>>> On Wed, Nov 23, 2016 at 02:57:07PM +0100, Martin Liška wrote: >>>>> I started review process in libsanitizer: https://reviews.llvm.org/D26965 >>>>> And I have a question that was asked in the review: can we distinguish >>>>> between load and store >>>>> in case of having usage of ASAN_POISON? >>>> >>>> I think with ASAN_POISON it is indeed just loads from after scope that can >>>> be caught, a store overwrites the variable with a new value and when >>>> turning >>>> the store after we make the var no longer addressable into SSA form, we >>>> loose information about the out of scope store. Furthermore, if there is >>>> first a store and then a read, like: >>>> if (argc != 12312) >>>> { >>>> char my_char; >>>> ptr = &my_char; >>>> } >>>> *ptr = i + 26; >>>> return *ptr; >>>> we don't notice even the read. Not sure what could be done against that >>>> though. I think we'd need to hook into the into-ssa framework, there it >>>> should know the current value of the variable at the point of the store is >>>> result of ASAN_POISON and be able to instead of turning that >>>> my_char = _23; >>>> into >>>> my_char_35 = _23; >>>> turn it into: >>>> my_char_35 = ASAN_POISON (_23); >>>> which would represent after scope store into my_char. >>>> >>>> Not really familiar with into-ssa though to know where to do it. >>>> >>>> Jakub >>>> >>> >>> Richi, may I ask you for help with this question? >> >> Probably where we handle the CLOBBER case (rewrite_stmt, maybe_register_def), >> we do this for -Wuninitialized. >> >> Richard. > > Thanks for the tip, however as the optimization of memory address store + > load happens > before we rewrite my_char into SSA, it would be probably hard to guess which > memory > stores and loads should be preserved: > > use-after-scope-20.c.032t.ccp1: > main (int argc, char * * argv) > { > int my_char; > int * ptr; > int _1; > int _11; > > <bb 2> [0.0%]: > if (argc_4(D) != 12312) > goto <bb 3>; [0.0%] > else > goto <bb 4>; [0.0%] > > <bb 3> [0.0%]: > ASAN_MARK (2, &my_char, 4); > ptr_8 = &my_char; > ASAN_MARK (1, &my_char, 4); > > <bb 4> [0.0%]: > # ptr_2 = PHI <ptr_5(D)(2), ptr_8(3)> > _1 = argc_4(D) + 26; > *ptr_2 = _1; > _11 = *ptr_2; > return _11; > > }
The SSA renamer sees my_char = ASAN_MARK; ptr_8 = &my_char; my_char = ASAN_MARK; ? It does perform a DOM walk when updating the stmts so simply registering the appropriate current def should do the trick? > I sent updated version of patch to LLVM phabricator: > https://reviews.llvm.org/D26965 > > Hopefully we can cherry pick the patch very soon to our trunk. > > M. > >> >>> Thanks, >>> Martin >>> >