[llvm-dev] Asan code size overhead
Kostya Serebryany via llvm-dev
llvm-dev at lists.llvm.org
Wed Oct 26 12:58:49 PDT 2016
On Wed, Oct 26, 2016 at 7:42 AM, Shi, Steven <steven.shi at intel.com> wrote:
> Hi Kcc,
>
> I’m trying enabling the Asan in my firmware, but I find the asan
> instrumentation code size impact is too big for me. I just implement
> necessary firmware version runtime library functions (e.g.
> __asan_report_load8) with blank body firstly to pass the asan enabled
> build, but I find the new binary code size is already ~2.5 times as
> original one with asan disabled in GCC. I know Linux kernel already enabled
> the asan (a.k.a Kasan), and is there any magic of asan for Linux to control
> its code size impact?
>
I don't think there is much magic.
> Please advise how to mitigate the asan code size overhead.
>
First, need to figure out what parts of instrumentation increase the code
size the most.
Start from switching from inline instrumentation to instrumentation with
calls:
With Clang that is "-mllvm -asan-instrumentation-with-call-threshold=0",
gcc should have something similar.
W/o this flag the instrumentation will look like this:
.cfi_def_cfa_offset 16
movq %rdi, %rax
shrq $3, %rax
movb 2147450880(%rax), %al
testb %al, %al
jne .LBB0_1
.LBB0_3:
movl (%rdi), %eax
popq %rcx
retq
.LBB0_1:
movl %edi, %ecx
andl $7, %ecx
addl $3, %ecx
cmpb %al, %cl
jl .LBB0_3
# BB#2:
callq __asan_report_load4
With this flag it will look like this:
movq %rdi, %rbx
callq __asan_load4
movl (%rbx), %eax
Obviously, there is a cost in performance.
Clang (and recent gcc) also have a convenience
flag -fsanitize=kernel-address:
movq %rdi, %rbx
callq __asan_load4_noabort
movl (%rbx), %eax
If that does not solve your code size problem, let's look at it more.
--kcc
>
>
>
>
> *Steven Shi*
>
> *Intel\SSG\STO\UEFI Firmware*
>
>
>
> Tel: +86 021-61166522 <+86%2021%206116%206522>
>
> iNet: 821-6522
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161026/cf1e3834/attachment.html>
More information about the llvm-dev
mailing list