Hi I updated the patch and put it in attachment. gcc/ChangeLog:
2017-09-04 Wish Wu <wishwu...@gmail.com>
* asan.c (initialize_sanitizer_builtins):
* builtin-types.def (BT_FN_VOID_UINT8_UINT8):
(BT_FN_VOID_UINT16_UINT16):
(BT_FN_VOID_UINT32_UINT32):
(BT_FN_VOID_FLOAT_FLOAT):
(BT_FN_VOID_DOUBLE_DOUBLE):
(BT_FN_VOID_UINT64_PTR):
* common.opt:
* flag-types.h (enum sanitize_coverage_code):
* opts.c (COVERAGE_SANITIZER_OPT):
(get_closest_sanitizer_option):
(parse_sanitizer_options):
(common_handle_option):
* sancov.c (instrument_cond):
(instrument_switch):
(sancov_pass):
* sanitizer.def (BUILT_IN_SANITIZER_COV_TRACE_CMP1):
(BUILT_IN_SANITIZER_COV_TRACE_CMP2):
(BUILT_IN_SANITIZER_COV_TRACE_CMP4):
(BUILT_IN_SANITIZER_COV_TRACE_CMP8):
(BUILT_IN_SANITIZER_COV_TRACE_CMPF):
(BUILT_IN_SANITIZER_COV_TRACE_CMPD):
(BUILT_IN_SANITIZER_COV_TRACE_SWITCH):
gcc/testsuite/ChangeLog:
2017-09-04 Wish Wu <wishwu...@gmail.com>
* gcc.dg/sancov/basic3.c: New test.
I think the aim of "trace-cmp" is finding reasonable values in runtime, playing
approximate tricks when fuzzing.
We don't need to save all of values from low_case to high_case, there may be
too much values and wasting resource.
For code :
void bar (void);
void
foo (int x)
{
if (x == 21 || x == 64 || x == 98 || x == 135)
bar ();
}
GIMPLE IL on x86_64:
1
2 ;; Function foo (foo, funcdef_no=0, decl_uid=2161, cgraph_uid=0,
symbol_order=0)
3
4 foo (int x)
5 {
6 unsigned int _5;
7 unsigned int _6;
8 unsigned int _7;
9 unsigned int _8;
10 unsigned int _9;
11 unsigned int _10;
12 unsigned int _11;
13 unsigned int _12;
14
15 <bb 2> [0.00%] [count: INV]:
16 _5 = (unsigned int) x_2(D);
17 _6 = (unsigned int) 21;
18 __builtin___sanitizer_cov_trace_cmp4 (_5, _6);
19 if (x_2(D) == 21)
20 goto <bb 6>; [INV] [count: INV]
21 else
22 goto <bb 3>; [INV] [count: INV]
23
24 <bb 3> [0.00%] [count: INV]:
25 _7 = (unsigned int) x_2(D);
26 _8 = (unsigned int) 64;
27 __builtin___sanitizer_cov_trace_cmp4 (_7, _8);
28 if (x_2(D) == 64)
29 goto <bb 6>; [INV] [count: INV]
30 else
31 goto <bb 4>; [INV] [count: INV]
32
33 <bb 4> [0.00%] [count: INV]:
34 _9 = (unsigned int) x_2(D);
35 _10 = (unsigned int) 98;
36 __builtin___sanitizer_cov_trace_cmp4 (_9, _10);
37 if (x_2(D) == 98)
38 goto <bb 6>; [INV] [count: INV]
39 else
40 goto <bb 5>; [INV] [count: INV]
41
42 <bb 5> [0.00%] [count: INV]:
43 _11 = (unsigned int) x_2(D);
44 _12 = (unsigned int) 135;
45 __builtin___sanitizer_cov_trace_cmp4 (_11, _12);
46 if (x_2(D) == 135)
47 goto <bb 6>; [INV] [count: INV]
48 else
49 goto <bb 7>; [INV] [count: INV]
50
51 <bb 6> [0.00%] [count: INV]:
52 bar ();
53
54 <bb 7> [0.00%] [count: INV]:
55 return;
56
57 }
58
59
It actually catches reasonable and meaningful values.
Maybe we can improve it in the future for tracing all of expression for
comparison.
Wish Wu
------------------------------------------------------------------
From:Dmitry Vyukov <dvyu...@google.com>
Time:2017 Sep 3 (Sun) 19:05
To:Wish Wu <weixi....@antfin.com>
Cc:Jakub Jelinek <ja...@redhat.com>; gcc <gcc@gcc.gnu.org>; gcc-patches
<gcc-patc...@gcc.gnu.org>; Jeff Law <l...@redhat.com>; wishwu007
<wishwu...@gmail.com>
Subject:Re: Add support to trace comparison instructions and switch statements
On Sun, Sep 3, 2017 at 12:38 PM, 吴潍浠(此彼) <weixi....@antfin.com> wrote:
> Hi
> I will update the patch according to your requirements, and with some my
> suggestions.
> It will take me one or two days.
Thanks! No hurry, just wanted to make sure you still want to pursue this.
> Wish Wu
>
> ------------------------------------------------------------------
> From:Dmitry Vyukov <dvyu...@google.com>
> Time:2017 Sep 3 (Sun) 18:21
> To:Jakub Jelinek <ja...@redhat.com>
> Cc:Wish Wu <weixi....@antfin.com>; gcc <gcc@gcc.gnu.org>; gcc-patches
> <gcc-patc...@gcc.gnu.org>; Jeff Law <l...@redhat.com>; wishwu007
> <wishwu...@gmail.com>
> Subject:Re: Add support to trace comparison instructions and switch statements
>
>
> On Sun, Sep 3, 2017 at 12:19 PM, Dmitry Vyukov <dvyu...@google.com> wrote:
>> On Sun, Sep 3, 2017 at 12:01 PM, Jakub Jelinek <ja...@redhat.com> wrote:
>>> On Sun, Sep 03, 2017 at 10:50:16AM +0200, Dmitry Vyukov wrote:
>>>> What we instrument in LLVM is _comparisons_ rather than control
>>>> structures. So that would be:
>>>> _4 = x_8(D) == 98;
>>>> For example, result of the comparison can be stored into a bool struct
>>>> field, and then used in branching long time after. We still want to
>>>> intercept this comparison.
>>>
>>> Then we need to instrument not just GIMPLE_COND, which is the stmt
>>> where the comparison decides to which of the two basic block successors to
>>> jump, but also GIMPLE_ASSIGN with tcc_comparison class
>>> gimple_assign_rhs_code (the comparison above), and maybe also
>>> GIMPLE_ASSIGN with COND_EXPR comparison code (that is say
>>> _4 = x_1 == y_2 ? 23 : _3;
>>> ).
>>>
>>>> > Perhaps for -fsanitize-coverage= it might be a good idea to force
>>>> > LOGICAL_OP_NON_SHORT_CIRCUIT/BRANCH_COST or whatever affects GIMPLE
>>>> > decisions mentioned above so that the IL is closer to what the user
>>>> > wrote.
>>>>
>>>> If we recurse down to comparison operations and instrument them, this
>>>> will not be so important, right?
>>>
>>> Well, if you just handle tcc_comparison GIMPLE_ASSIGN and not GIMPLE_COND,
>>> then you don't handle many comparisons from the source code. And if you
>>> handle both, some of the GIMPLE_CONDs might be just artificial comparisons.
>>> By pretending small branch cost for the tracing case you get fewer
>>> artificial comparisons.
>>
>>
>> Are these artificial comparisons on BOOLEAN_TYPE? I think BOOLEAN_TYPE
>> needs to be ignored entirely, there is just like 2 combinations of
>> possible values.
>> If not, then what it is? Is it a dup of previous comparisons?
>>
>> I am not saying these modes should not be enabled. You know much
>> better. I just wanted to point that that integer comparisons is what
>> we should be handling.
>>
>> Your example:
>>
>> _1 = x_8(D) == 21;
>> _2 = x_8(D) == 64;
>> _3 = _1 | _2;
>> if (_3 != 0)
>>
>> raises another point. Most likely we don't want to see speculative
>> comparisons. At least not yet (we will see them once we get through
>> the first comparison). So that may be another reason to enable these
>> modes (make compiler stick closer to original code).
>
> Wait, it is not speculative in this case as branch is on _1 | _2. But
> still, it just makes it harder for fuzzer to get through as it needs
> to guess both values at the same time rather then doing incremental
> progress.
gcc-svn-201709041958.patch
Description: Binary data
