-
Notifications
You must be signed in to change notification settings - Fork 1k
AddressSanitizerClangVsGCC (3.8 vs 6.0)
This page describes differences in AddressSanitizer between Clang and GCC (both runtime and compiler parts). In general, most differences are caused by different compiler part implementations in Clang and GCC.
The library part is periodically merged from LLVM to GCC and doesn't contain serious incompatibilities (although GCC still needs some local workarounds, see below).
The comparison was performed for relatively fresh versions of mentioned tools:
Clang: clang version 3.8.0 r255627 (http://llvm.org/viewvc/llvm-project/cfe?view=revision&revision=255627)
LLVM: LLVM version 3.8.0 r255629 (http://llvm.org/viewvc/llvm-project?view=revision&revision=255629)
Compiler-rt: r255594 (http://llvm.org/viewvc/llvm-project/compiler-rt?view=revision&revision=255594)
GCC: gcc version 6.0.0 20151215 (experimental) r231646 (https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=231646)
std containers overflow detection
- LLVM: yes (std::vector)
- GCC: google branch (std::vector)
- Bugs/ML: http://llvm.org/viewvc/llvm-project?view=revision&revision=208319
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=207517
Support new kinds of bugs detection.
dynamic alloca overflow detection
- LLVM: yes
- GCC: compiler support missing
- Bugs/ML:
Support new kinds of bugs detection.
using private aliases for globals
- LLVM: no, support ODR violation detection, mixing instrumented code with non-instrumented is not safe.
- GCC: yes, doesn't support ODR violation detection, mixing instrumented code with non-instrumented is safe.
- Bugs/ML: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68016
https://github.com/google/sanitizers/issues/398
https://llvm.org/bugs/show_bug.cgi?id=24486
GCC flaws:
- false negatives on global variables when copy relocations are involved.
- ODR violation detection doesn't work.
LLVM flaws:
- we need to re-link our binaries against each time we add/remove sanitized library.
- false positives or internal ASan CHECK failures can occur when mixing instrumented code with non-instrumented.
ODR violation detection
- LLVM: yes
- GCC: no
- Bugs/ML: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
https://github.com/google/sanitizers/issues/398
GCC flaws:
- ODR violation detection doesn't work.
LLVM flaws:
- false positives or internal ASan CHECK failures can occur when mixing instrumented code with non-instrumented.
symbol size changing for global variables
- LLVM: yes
- GCC: no
- Bugs/ML: https://github.com/google/sanitizers/issues/619
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68016
https://sourceware.org/bugzilla/show_bug.cgi?id=19173
In Clang, ASan changes size of global variables by appending redzone size to it. This is an ABI change and may cause runtime errors when/if other shared modules have been linked against non-sanitized version of the library. However, given that Clang should support not only ELF format (e.g. Windows and OS/X use different ones), it's complicated to make sure that target linker won't cut out right redzone for global variables if not include it in symbol itself. GCC ASan generally supports ELF only, so it doesn't have such problems.
adaptive global redzone sizes
- LLVM: yes
- GCC: no
- Bugs/ML:
Possible better layout for global variables in Clang.
KASan support
- LLVM: limited
- GCC: yes
- Bugs/ML: https://www.kernel.org/doc/Documentation/kasan.txt
Use Asan for kernel. Linux kernel still cannot be built via clang for most targets (for x86{,_64} you still need apply special patches).
asan_experiments support
- LLVM: yes (experimental)
- GCC: no
- Bugs/ML: http://llvm.org/viewvc/llvm-project?view=revision&revision=232501
http://llvm.org/viewvc/llvm-project?view=revision&revision=232502
This feature is experimental. The experiments can be used to evaluate potential optimizations that remove instrumentation (assess false negatives). This way we can figure out, what optimization causes false negatives in much easier way.
invalid pointer pairs detection
- LLVM: yes (experimental, heap only)
- GCC: no
- Bugs/ML:
This feature is experimental. Instrument <, <=, >, >=, - with pointer operands. Used to enable detection of invalid comparison operators on pointers.
lifetime checking
- LLVM: yes (experimental, enabled by default in clang 4.0)
- GCC: no, but would become available in GCC 7
- Bugs/ML: https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00468.html https://github.com/google/sanitizers/wiki/AddressSanitizerExampleUseAfterScope https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=241896
This feature is experimental. Allows detect use after scope bugs.
default runtime library linkage
- LLVM: static
- GCC: dynamic
- Bugs/ML: https://github.com/google/sanitizers/wiki/AddressSanitizerAsDso
https://github.com/google/sanitizers/issues/147
http://reviews.llvm.org/D3042
Dynamic linkage cons:
- Worse performance (ASAN run-time is called via PLT even in the main executable)
- Issue 147 (on Google Code) (can't use -static-libstdc++-Harder deployment (need to carry the DSO around)
- __asan_init is not called from preinit_array and so there is a risk that an instrumented code will get called before __asan_init (may cause SEGV at startup; still unlikely)
Dynamic linkage proc:
- Smaller disk usage and memory footprint when multiple processes are running with ASan.
- Potential ability to bring old ASAN-ified binaries to new systems
- Ability to LD_PRELOAD ASAN-DSO
use explicit list of exported symbols
- LLVM: yes
- GCC: no
- Bugs/ML: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64234
In GCC, statically sanitized executables don't export ASan symbols. In particular, if executable is linked with -static-libasan, it won't export libasan public API (__asan_reportXYZ, etc.), causing dlopens of sanitized shared libraries to fail. Clang uses --dynamic-list link option to export public symbols and avoid such errors.
asan_symbolize script
- LLVM: yes
- GCC: no
- Bugs/ML:
The script itself is a useful feature, perhaps it should be embedded to GCC source tree as well.
ARM ABI for frame pointer extracting
- LLVM: LLVM ABI
- GCC: GCC ABI
- Bugs/ML: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771
GCC needs a special patch to handle the issue.
support ASan blacklist file
- LLVM: yes
- GCC: no
- Bugs/ML: http://clang.llvm.org/docs/AddressSanitizer.html#suppressing-errors-in-recompiled-code-blacklist
https://gcc.gnu.org/ml/gcc-patches/2013-12/msg00649.html
Clang is more flexible in controlling instrumentation.
support sanitizer coverage
- LLVM: yes
- GCC: very limited, for Linux kernel only
- Bugs/ML: http://clang.llvm.org/docs/SanitizerCoverage.html
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00299.html
In Clang, ASan has good integration with fast and lightweight fuzzing library Libfuzzer (http://llvm.org/docs/LibFuzzer.html). In GCC, ASan is integrated with AFL only (http://lcamtuf.coredump.cx/afl/).
reports deduplication for ASan recovery mode
- LLVM: yes
- GCC: no
- Bugs/ML: http://reviews.llvm.org/D15080
In Clang, ASan recovery mode is much usable. This feature should be merged to GCC.
support old Linux kernels (< 3.0)
- LLVM: no
- GCC: yes
- Bugs/ML:
In GCC, ASan works for older Linux kernels. GCC uses local workarounds in libsanitizer to support this feature.
symbolizer implementation
- LLVM: LLVM symbolizer
- GCC: Libbacktrace
- Bugs/ML:
GCC uses embedded libbacktrace library for symbolization that's statically linked with libasan. LLVM needs a separate llvm-symbolizer binary to print nice reports.
Support for no_sanitize
attribute
- LLVM: yes
- GCC: no
- Bugs/ML: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78204
In LLVM it's possible to disable custom UBSan checker (e.g. float-divide-by-zero
) while GCC doesn't support such functionality.
Instrument function call arguments whose address is taken
- LLVM: yes, but only for small types
- GCC: no
- Bugs/ML: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81040
https://github.com/google/sanitizers/issues/823
LLVM can find more bugs in function arguments