Hi I updated the patch and put it in attachment. gcc/ChangeLog: 2017-09-04 Wish Wu * 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 * 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 [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 ; [INV] [count: INV] 21 else 22 goto ; [INV] [count: INV] 23 24 [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 ; [INV] [count: INV] 30 else 31 goto ; [INV] [count: INV] 32 33 [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 ; [INV] [count: INV] 39 else 40 goto ; [INV] [count: INV] 41 42 [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 ; [INV] [count: INV] 48 else 49 goto ; [INV] [count: INV] 50 51 [0.00%] [count: INV]: 52 bar (); 53 54 [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 Time:2017 Sep 3 (Sun) 19:05 To:Wish Wu Cc:Jakub Jelinek ; gcc ; gcc-patches ; Jeff Law ; wishwu007 Subject:Re: Add support to trace comparison instructions and switch statements On Sun, Sep 3, 2017 at 12:38 PM, 吴潍浠(此彼) 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 > Time:2017 Sep 3 (Sun) 18:21 > To:Jakub Jelinek > Cc:Wish Wu ; gcc ; gcc-patches ; Jeff Law ; wishwu007 > Subject:Re: Add support to trace comparison instructions and switch statements > > > On Sun, Sep 3, 2017 at 12:19 PM, Dmitry Vyukov wrote: >> On Sun, Sep 3, 2017 at 12:01 PM, Jakub Jelinek 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.