Skip to content

AddressSanitizerClangVsGCC (3.8 vs 6.0)

Jump to bottom
chefmax edited this page Jun 19, 2017 · 4 revisions

Clang 3.8 vs GCC 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)

Feature:

std containers overflow detection

Cons and Pros:

Support new kinds of bugs detection.


Feature:

dynamic alloca overflow detection

  • LLVM: yes
  • GCC: compiler support missing
  • Bugs/ML:
Cons and Pros:

Support new kinds of bugs detection.


Feature:

using private aliases for globals

Cons and Pros:

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.

Feature:

symbol size changing for global variables

Cons and Pros:

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.


Feature:

adaptive global redzone sizes

  • LLVM: yes
  • GCC: no
  • Bugs/ML:
Cons and Pros:

Possible better layout for global variables in Clang.


Feature:

KASan support

Cons and Pros:

Use Asan for kernel. Linux kernel still cannot be built via clang for most targets (for x86{,_64} you still need apply special patches).


Feature:

asan_experiments support

Cons and Pros:

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.


Feature:

invalid pointer pairs detection

  • LLVM: yes (experimental)
  • GCC: no
  • Bugs/ML:
Cons and Pros:

This feature is experimental. Support new kinds of bugs detection.


Feature:

lifetime checking

Cons and Pros:

This feature is experimental. Allows detect use after scope bugs.


Feature:

default runtime library linkage

Cons and Pros:

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

Feature:

use explicit list of exported symbols

Cons and Pros:

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.


Feature:

asan_symbolize script

  • LLVM: yes
  • GCC: no
  • Bugs/ML:
Cons and Pros:

The script itself is a useful feature, perhaps it should be embedded to GCC source tree as well.


Feature:

ARM ABI for frame pointer extracting

Cons and Pros:

GCC needs a special patch to handle the issue.


Feature:

support ASan blacklist file

Cons and Pros:

Clang is more flexible in controlling instrumentation.


Feature:

support sanitizer coverage

Cons and Pros:

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/).


Feature:

reports deduplication for ASan recovery mode

Cons and Pros:

In Clang, ASan recovery mode is much usable. This feature should be merged to GCC.


Feature:

support old Linux kernels (< 3.0)

  • LLVM: no
  • GCC: yes
  • Bugs/ML:
Cons and Pros:

In GCC, ASan works for older Linux kernels. GCC uses local workarounds in libsanitizer to support this feature.


Feature:

symbolizer implementation

  • LLVM: LLVM symbolizer
  • GCC: Libbacktrace
  • Bugs/ML:
Cons and Pros:

GCC uses embedded libbacktrace library for symbolization that's statically linked with libasan. LLVM needs a separate llvm-symbolizer binary to print nice reports.

Feature:

Support for no_sanitize attribute

Cons and Pros:

In LLVM it's possible to disable custom UBSan checker (e.g. float-divide-by-zero) while GCC doesn't support such functionality.


Feature:

Instrument function call arguments whose address is taken

Cons and Pros:

LLVM can find more bugs in function arguments

Clone this wiki locally