While born originally at Google as projects for LLVM, AddressSanitizer and ThreadSanitizer have been
ported to GCC and will be part of the forthcoming GCC 4.8 compiler release. Back at Google, they're onto developing MemorySanitizer for LLVM.
AddressSanitizer (ASAN) was developed at Google to be a fast memory error detector. ASAN is capable of finding use-after-free and heap, stack, and global buffer overflow bugs within C and C++ programs. AddressSanitizer was merged into LLVM 3.1 earlier this year and running an ASAN-enabled program leads to only about a 2x slowdown for developers wishing to easily spot these memory errors within their programs. The GCC port of ASAN is currently supported on IA-32, x86-64, and x32 architectures under Linux.
ThreadSanitizer (TSAN) is another newer Google project for detecting data race within C/C++ programs. ThreadSanitizier is based upon the popular Valgrind program and is similar to Helgrind. The slowdown of running a ThreadSanitizier-enabled LLVM program is around 5~15x slower and also requires a run-time library aside from a supported compiler. Within LLVM, ThreadSanitizer is much more primitive and in an alpha state compared to ASAN.
With GCC 4.8, both AddressSanitizer and ThreadSanitizer are available for detecting memory errors and data races, respectively. For tapping AddressSanitizer in GCC, the -fsanitize=address switch must be passed to GCC when building a program. The -fno-omit-frame-pointer switch can also be optionally passed for nicer stack-traces. If you wish to utilize ThreadSanitizer in GCC 4.8, the -fsanitize=thread switch must be thrown, but this port is only working on 64-bit Linux.
AddressSanitizer (ASAN) was developed at Google to be a fast memory error detector. ASAN is capable of finding use-after-free and heap, stack, and global buffer overflow bugs within C and C++ programs. AddressSanitizer was merged into LLVM 3.1 earlier this year and running an ASAN-enabled program leads to only about a 2x slowdown for developers wishing to easily spot these memory errors within their programs. The GCC port of ASAN is currently supported on IA-32, x86-64, and x32 architectures under Linux.
ThreadSanitizer (TSAN) is another newer Google project for detecting data race within C/C++ programs. ThreadSanitizier is based upon the popular Valgrind program and is similar to Helgrind. The slowdown of running a ThreadSanitizier-enabled LLVM program is around 5~15x slower and also requires a run-time library aside from a supported compiler. Within LLVM, ThreadSanitizer is much more primitive and in an alpha state compared to ASAN.
With GCC 4.8, both AddressSanitizer and ThreadSanitizer are available for detecting memory errors and data races, respectively. For tapping AddressSanitizer in GCC, the -fsanitize=address switch must be passed to GCC when building a program. The -fno-omit-frame-pointer switch can also be optionally passed for nicer stack-traces. If you wish to utilize ThreadSanitizer in GCC 4.8, the -fsanitize=thread switch must be thrown, but this port is only working on 64-bit Linux.
Meanwhile, still being developed at Google for LLVM (and presumably ported to GCC too) is MemorySanitizer. MemorySanitizer is intended to spot uninitialized memory reads and shares concepts with Valgrind and Memcheck but uses compile-time instrumentation within LLVM and 1:1 direct shadow memory mapping. MemorySanitizer promises to be much faster than Valgrind (2~3x vs. 20x) for spotting these uninitialized memory reads in C/C++ code-bases. For those interested in more details on MemorySanitizier (MSAN) there is a PDF poster from the talk given earlier this month at the LLVM Developers' Meeting.
1141
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
