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;
}
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
>>
