On 11/02/2016 10:59 AM, Jakub Jelinek wrote:
> On Wed, Nov 02, 2016 at 10:36:44AM +0100, Martin Liška wrote:
>> On 11/01/2016 03:53 PM, Jakub Jelinek wrote:
>>> What kind of false positives it is for each case? Is it with normal
>>> asan-bootstrap (without your -fsanitize-use-after-scope changes), or
>>> only with those changes, or only with those changes and
>>> -fsanitize-use-after-scope used during bootstrap?
>>
>> Ok, the situation is simpler than I thought:
>
> CCing also Marek.
>>
>> #include <stdio.h>
>>
>> int main(int argc, char **argv)
>> {
>> int *ptr;
>>
>> switch (argc)
>> {
>> int a;
>>
>> case 1:
>> break;
>>
>> default:
>> ptr = &a;
>> break;
>> }
>>
>> fprintf (stderr, "v: %d\n", *ptr);
>> return 0;
>> }
>>
>> Which is gimplified as:
>>
>> int * ptr;
>>
>> switch (argc) <default: <D.2575>, case 1: <D.2573>>
>> {
>> int a;
>>
>> try
>> {
>> ASAN_MARK (2, &a, 4);
>> <D.2573>:
>> goto <D.2574>;
>> <D.2575>:
>> ptr = &a;
>> goto <D.2574>;
>> }
>> finally
>> {
>> ASAN_MARK (1, &a, 4);
>> }
>> }
>> <D.2574>:
>> _1 = *ptr;
>> stderr.0_2 = stderr;
>> fprintf (stderr.0_2, "v: %d\n", _1);
>> D.2577 = 0;
>> return D.2577;
>> }
>> D.2577 = 0;
>> return D.2577;
>>
>> and thus we get:
>> /tmp/switch-case.c:9:11: warning: statement will never be executed
>> [-Wswitch-unreachable]
>> int a;
>>
>> I'm wondering where properly fix that, we can either find all these
>> ASAN_MARKs in gimplify_switch_expr
>> and distribute it to all labels (which are gimplified). Or we can put such
>> variables to asan_poisoned_variables
>> if we have information that we're gimplifing statements before a first
>> label. Do we know that from gimple context?
>> If so, these variables will be unpoisoned at the very beginning of each
>> label and the ASAN_MARK call in between
>> switch statement and a first label can be removed.
>
> Wouldn't it be easiest if -Wswitch-unreachable warning just ignored
> the ASAN_MARK internal calls altogether?
> Do you emit there any other statements, or just ASAN_MARK and nothing else?
Yep, skipping warning can be done easily, however gimplified code is wrong as
un-poisoning is not done for variable (even for a valid program).
>
> Shouldn't there be also ASAN_MARK on the implicit gotos from the switch
> statement? Otherwise, consider this being done in a loop, after the first
> iteration you ASAN_MARK (1, &a, 4) (i.e. poison), then you iterate say with
> args 1 and have in case 1: a = 0;, won't that trigger runtime error?
Hopefully having the un-poisoning call be encapsulated in finally block would
properly
clean up the variable. Or am I wrong?
Martin
>
> Jakub
>