Dear All,
We have a new release of Clang with SAFECode technology for detecting memory safety errors. Memory safety checking (SAFECode for short) can be turned on with a single command line switch to clang/clang++. The SAFECode techniques do not change the behavior of the clang/clang++ compilers in any way when the switch is turned off, so this can be used as a drop-in replacement for clang/clang++.
Clang with SAFECode has the following advantages over tools such as Valgrind:
o) It is faster since it does not use dynamic binary translation and can optimize away some run-time checks.
o) It is more accurate since it knows the boundaries of individual stack and global objects (Valgrind's ptrcheck tool needs to use heuristics to find these boundaries).
o) It provides better error diagnostics that give more useful information about each memory safety violation.
The current release primarily detects dereferences of pointers that are generated from buffer overflows. There are many features from the LLVM 2.7 version of SAFECode that we are updating to work with LLVM mainline and will be incorporating into our version of Clang soon. These features include:
o) Detecting invalid memory accesses (e.g., dangling pointer dereferences)
o) Detecting invalid calls to free()
o) Detecting uses of uninitialized pointers
o) Detecting memory errors caused by misuse of C standard library functions
o) Several optimizations, including type-safe load/store check removal and a loop hoisting optimization
Clang with SAFECode is available for download either in source form for Linux and Mac OS X or as a pre-built Mac OS X binary at SAFECode: Downloads. The source code is also available directly from our SAFECode Subversion repository; download directions are given on the web page above.
We're very interested in feedback (positive, negative, or otherwise).
Regards,
John Criswell
Hi John,
We have a new release of Clang with SAFECode technology for detecting
memory safety errors. Memory safety checking (SAFECode for short) can be
turned on with a single command line switch to clang/clang++. The
SAFECode techniques do not change the behavior of the clang/clang++
compilers in any way when the switch is turned off, so this can be used
as a drop-in replacement for clang/clang++.
sounds great! However, do you have to use clang (making it useless for
Fortran etc), or can it work on LLVM IR too?
Ciao, Duncan.
Hi John,
We have a new release of Clang with SAFECode technology for detecting
memory safety errors. Memory safety checking (SAFECode for short) can be
turned on with a single command line switch to clang/clang++. The
SAFECode techniques do not change the behavior of the clang/clang++
compilers in any way when the switch is turned off, so this can be used
as a drop-in replacement for clang/clang++.
sounds great! However, do you have to use clang (making it useless for
Fortran etc), or can it work on LLVM IR too?
All of the analysis and transforms work on LLVM IR and are, therefore, language independent(*). We simply integrated the LLVM passes into Clang so that they are easier to use.
-- John T.
(*) One caveat here is that we need to know the name of the functions used for allocating and freeing memory. These tend to differ between languages, but enhancing the code to recognize them is trivial.
Dear All,
We have a new release of Clang with SAFECode technology for detecting
memory safety errors. Memory safety checking (SAFECode for short) can be
turned on with a single command line switch to clang/clang++. The
SAFECode techniques do not change the behavior of the clang/clang++
compilers in any way when the switch is turned off, so this can be used
as a drop-in replacement for clang/clang++.
Clang with SAFECode has the following advantages over tools such as
Valgrind:
o) It is faster since it does not use dynamic binary translation and can
optimize away some run-time checks.
John,
Do you have performance figures for SAFECode, e.g. on Spec CPU2006 or similar benchmarks?
Valgrind shows 20x on CPU2006, DrMemory shows 10x (http://groups.csail.mit.edu/commit/papers/2011/bruening-cgo11-drmemory.pdf).
AddressSanitizer (which finds a different set of bugs compared to Valgrind/DrMemory, but very similar to SAFECode) has less than 2x overhead (http://code.google.com/p/address-sanitizer/wiki/PerformanceNumbers).
Thanks,
–kcc
John,
The release source code (sc-main.tar) won't compile cleanly under Debian6-i386 (gcc/g++: 4.4.5).
The compiler back trace is attached.
Please fix it/them and repost.
Or, 64b system is a requirement?
Thank you
Chuck
llvm[4]: Compiling TypeRuntime.cpp for Release+Asserts build (PIC)
cc1plus: warnings being treated as errors
/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/llvm/projects/poolalloc/runtime/DynamicTypeChecks/TypeRuntime.cpp:52: error: integer constant is too large for ‘long’ type
/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/llvm/projects/poolalloc/runtime/DynamicTypeChecks/TypeRuntime.cpp:99: error: integer constant is too large for ‘long’ type
/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/llvm/projects/poolalloc/runtime/DynamicTypeChecks/TypeRuntime.cpp:110: error: integer constant is too large for ‘long’ type
/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/llvm/projects/poolalloc/runtime/DynamicTypeChecks/TypeRuntime.cpp: In function ‘uintptr_t maskAddress(void*)’:
/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/llvm/projects/poolalloc/runtime/DynamicTypeChecks/TypeRuntime.cpp:102: error: left shift count >= width of type
/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/llvm/projects/poolalloc/runtime/DynamicTypeChecks/TypeRuntime.cpp: In function ‘void shadowInit()’:
/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/llvm/projects/poolalloc/runtime/DynamicTypeChecks/TypeRuntime.cpp:110: error: left shift count >= width of type
/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/llvm/projects/poolalloc/runtime/DynamicTypeChecks/TypeRuntime.cpp: In function ‘void getTypeTag(void*, uint64_t, TypeTagTy*, uint32_t)’:
/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/llvm/projects/poolalloc/runtime/DynamicTypeChecks/TypeRuntime.cpp:223: error: left shift count >= width of type
/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/llvm/projects/poolalloc/runtime/DynamicTypeChecks/TypeRuntime.cpp:223: error: comparison of unsigned expression < 0 is always false
make[4]: *** [/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/robj32/projects/poolalloc/runtime/DynamicTypeChecks/Release+Asserts/TypeRuntime.o] Error 1
make[4]: Leaving directory `/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/robj32/projects/poolalloc/runtime/DynamicTypeChecks'
make[3]: *** [all] Error 1
make[3]: Leaving directory `/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/robj32/projects/poolalloc/runtime'
make[2]: *** [all] Error 1
make[2]: Leaving directory `/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/robj32/projects/poolalloc'
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/czhao/ResearchTools/LLVM/SubProjects/Safecode/robj32/projects'
make: *** [all] Error 1
1836.706u 195.512s 9:33.06 354.6% 0+0k 304384+3596928io 1604pf+0w
Hi,
My apologies for the trouble.
I've disabled building DynamicTypeChecks for now (r138224) and now it
builds cleanly on 32bit for me here.
As for SAFECode support for 32bit vs 64bit, I believe 32bit should
work just fine although I haven't personally tested this.
Let me know if you have any further issues/questions.
~Will
Hi,
My apologies for the trouble.
I've disabled building DynamicTypeChecks for now (r138224) and now it
builds cleanly on 32bit for me here.
Thanks, Will.
Just as an FYI to everyone, SAFECode does not depend upon everything within the poolalloc project. The code that Will disabled is actually from another project and is not (currently) used by SAFECode.
As for SAFECode support for 32bit vs 64bit, I believe 32bit should
work just fine although I haven't personally tested this.
SAFECode was originally built on 32-bit systems, so I think it should still work. Chuck, if you find any more problems compiling or using SAFECode on 32-bit systems, please let us know. We need to support both 32- and 64- bit systems.
Regarding the rebuilding of the source tarball, I'll go ahead and update it since I'd like it to build on 32-bit systems. That said, in general, I prefer people to update from SVN. Is that something that you can do?
-- John T.