Hi
The trace-div and trace-gep options seems be used to evaluate corpus
to trigger specific kind of bugs. And they don't have strong effect to coverage.
The trace-pc-guard is useful, but it may be much more complex than trace-pc.
I think the best benefit of trace-pc-guard is avoiding dealing ASLR of programs,
especially programs with dlopen(). Seems hard to implement it in Linux kernel.
The inline-8bit-counters and pc-table is too close to implementation of fuzz
tool and
option trace-pc-guard .
I am interesting in "stack-depth" and "func". If we trace user-defined
functions enter and exit,
we can calculate stack-depth and difference level of stack to past existed
stack.
Adding __sanitizer_cov_trace_pc_{enter,exit} is easy , but it is not standard
of llvm.
How do you think Dmitry ?
Wish Wu
------------------------------------------------------------------
From:Jakub Jelinek <ja...@redhat.com>
Time:2017 Sep 6 (Wed) 22:37
To:Wish Wu <weixi....@antfin.com>
Cc:Dmitry Vyukov <dvyu...@google.com>; gcc-patches <gcc-patches@gcc.gnu.org>;
Jeff Law <l...@redhat.com>; wishwu007 <wishwu...@gmail.com>
Subject:Re: Add support to trace comparison instructions and switch statements
On Wed, Sep 06, 2017 at 07:47:29PM +0800, 吴潍浠(此彼) wrote:
> Hi Jakub
> I compiled libjpeg-turbo and libdng_sdk with options "-g -O3 -Wall
> -fsanitize-coverage=trace-pc,trace-cmp -fsanitize=address".
> And run my fuzzer with pc and cmp feedbacks for hours. It works fine.
> About __sanitizer_cov_trace_cmp{f,d} , yes, it isn't provided by llvm. But
> once we trace integer comparisons, why not real type comparisons.
> I remember Dmitry said it is not enough useful to trace real type comparisons
> because it is rare to see them in programs.
> But libdng_sdk really has real type comparisons. So I want to keep them and
> implementing __sanitizer_cov_trace_const_cmp{f,d} may be necessary.
Ok. Please make sure those entrypoints make it into the various example
__sanitier_cov_trace* fuzzer implementations though, so that people using
-fsanitize-coverage=trace-cmp in GCC will not need to hack stuff themselves.
At least it should be added to sanitizer_common (both in LLVM and GCC).
BTW, https://clang.llvm.org/docs/SanitizerCoverage.html shows various other
-fsanitize-coverage= options, some of them terribly misnamed (e.g. trace-gep
using some weirdo LLVM IL acronym instead of being named by what it really
traces (trace-array-idx or something similar)).
Any plans to implement some or all of those?
Jakub
