<br><br><div class="gmail_quote">On Thu, Aug 18, 2011 at 7:56 AM, John Criswell <span dir="ltr"><<a href="mailto:criswell@illinois.edu">criswell@illinois.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Dear All,<br>
<br>
We have a new release of Clang with SAFECode technology for detecting<br>
memory safety errors. Memory safety checking (SAFECode for short) can be<br>
turned on with a single command line switch to clang/clang++. The<br>
SAFECode techniques do not change the behavior of the clang/clang++<br>
compilers in any way when the switch is turned off, so this can be used<br>
as a drop-in replacement for clang/clang++.<br>
<br>
Clang with SAFECode has the following advantages over tools such as<br>
Valgrind:<br>
<br>
o) It is faster since it does not use dynamic binary translation and can<br>
optimize away some run-time checks.<br></blockquote><div><br></div><div><br></div><div>John, </div><div><br></div><div>Do you have performance figures for SAFECode, e.g. on Spec CPU2006 or similar benchmarks?</div><div><br>
</div><div>Valgrind shows 20x on CPU2006, DrMemory shows 10x (<a href="http://groups.csail.mit.edu/commit/papers/2011/bruening-cgo11-drmemory.pdf">http://groups.csail.mit.edu/commit/papers/2011/bruening-cgo11-drmemory.pdf</a>).</div>
<div>AddressSanitizer (which finds a different set of bugs compared to Valgrind/DrMemory, but very similar to SAFECode) has less than 2x overhead (<a href="http://code.google.com/p/address-sanitizer/wiki/PerformanceNumbers">http://code.google.com/p/address-sanitizer/wiki/PerformanceNumbers</a>).</div>
<div><br></div><div><br></div><div>Thanks, </div><div><br></div><div>--kcc </div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

o) It is more accurate since it knows the boundaries of individual stack<br>
and global objects (Valgrind's ptrcheck tool needs to use heuristics to<br>
find these boundaries).<br>
o) It provides better error diagnostics that give more useful<br>
information about each memory safety violation.<br>
<br>
The current release primarily detects dereferences of pointers that are<br>
generated from buffer overflows.  There are many features from the LLVM<br>
2.7 version of SAFECode that we are updating to work with LLVM mainline<br>
and will be incorporating into our version of Clang soon.  These<br>
features include:<br>
<br>
o) Detecting invalid memory accesses (e.g., dangling pointer dereferences)<br>
o) Detecting invalid calls to free()<br>
o) Detecting uses of uninitialized pointers<br>
o) Detecting memory errors caused by misuse of C standard library functions<br>
o) Several optimizations, including type-safe load/store check removal<br>
and a loop hoisting optimization<br>
<br>
Clang with SAFECode is available for download either in source form for<br>
Linux and Mac OS X or as a pre-built Mac OS X binary at<br>
<a href="http://sva.cs.illinois.edu/downloads.html" target="_blank">http://sva.cs.illinois.edu/downloads.html</a>.  The source code is also<br>
available directly from our SAFECode Subversion repository; download<br>
directions are given on the web page above.<br>
<br>
We're very interested in feedback (positive, negative, or otherwise).<br>
<br>
Regards,<br>
<br>
John Criswell<br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br>