[PATCH] Support asan-instrumentation-with-call-threshold in GCC

[Konstantin Serebryany]

my 2c

- using instrumentation via calls adds extra 1.5x-2.x slowdown
- it indeed saves code size
- in LLVM this was done mostly to overcome the compile time problem on
huge functions
- in GCC we will indeed need this for kasan
(https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel)
- even for kasan this is not a long term solution -- once we finalize
the kasan memory layout we'll want to inline the instrumentation. But
that may take long time to come there.
- it would be nice to have the name prefix configurable from command
line (${PREFIX}_load1 instead of __asan_load1) because kasan uses
different names already.


On Mon, May 26, 2014 at 7:58 PM, Yury Gribov <y.gribov@samsung.com> wrote:
> Hi all,
>
> This patch adds support for outline Asan instrumentation (i.e. function
> calls instead of inline checks). This has been recently added to LLVM to
> * reduce long compiler runtimes on large functions with huge (over 10K)
> number of memory accesses (http://llvm.org/bugs/show_bug.cgi?id=12653)
> * a step to full Kasan support in GCC
> * reduce code size overhead
>
> Implementation is a bit different from LLVM: GCC starts generating function
> calls after overflowing the threshold whereas LLVM replaces all
> instrumentations once total number is estimated to be larger than treshold.
> Making implementations more similar would require bigger rewrite of Asan
> which I would prefer to avoid.
>
> The patch consists of two parts:
> * asan_negative_params_1.diff - support for negative parameters
> * asan_calls_1.diff - the proper
>
> Bootstrapped/regtested on x64.
>
> -Y