<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 5/3/11 1:52 PM, Kostya Serebryany wrote:
<blockquote
cite="mid:BANLkTi=SSetML4Nw3ES8qi3c6eLprSg6Zg@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<span class="Apple-style-span" style="border-collapse: collapse;
font-family: arial,sans-serif; font-size: 13px;">Hello,
<div><br>
</div>
<div>We've just released the first version of our LLVM-based
address sanity checker: AddressSanitizer (<a
moz-do-not-send="true"
href="http://code.google.com/p/address-sanitizer/"
target="_blank" style="color: rgb(0, 101, 204);">http://code.google.com/p/address-sanitizer/</a>).</div>
<div>The tool finds out-of-bound and use-after-free bugs (the
subset of bugs detectable by Valgrind/Memcheck); </div>
<div>it consists of a LLVM compiler plugin which performs simple
code instrumentation and a malloc replacement library. </div>
<div>The main advantage of the new tool is high speed: the
slowdown is usually within 2x-2.5x. </div>
<div>Detailed description of the algorithm is found here: <a
moz-do-not-send="true"
href="http://code.google.com/p/address-sanitizer/wiki/AddressSanitizerAlgorithm"
target="_blank" style="color: rgb(0, 101, 204);">http://code.google.com/p/address-sanitizer/wiki/AddressSanitizerAlgorithm</a></div>
<div>The tool is young, but it already can run the Chromium
browser (interactively!) and find bugs in it. <br>
</div>
</span></blockquote>
<br>
Interesting. We've been working on our own open-source memory
safety tool called SAFECode (<a class="moz-txt-link-freetext"
href="http://sva.cs.illinois.edu">http://sva.cs.illinois.edu</a>).
SAFECode has a number of nice features, including:<br>
<br>
o) It works on both Mac OS X and Linux (and should work on other
Unix platforms with little/no modification).<br>
o) It has options for performing safety checks on loads/stores and
on array/struct indexing operations.<br>
o) It can accurately detect array bounds violations on global and
stack objects as well as heap objects (unlike Valgrind, which must
use heuristics to identify global/stack object boundaries).<br>
o) It can optionally instrument C library functions to detect memory
safety errors.<br>
o) It has both simple and sophisticated optimization passes that
remove unneeded instrumentation.<br>
o) It has a debug instrumentation pass that can use LLVM debug
metadata to enhance instrumentation to include source filename /
line number info (although this code needs to be updated).<br>
o) It has features to make dangling pointer dereferences "safe" for
production code.<br>
o) It has an experimental mode for precise dangling pointer
detection.<br>
o) We have a new, faster memory object tracking run-time based on
Baggy Bounds Checking.<br>
<br>
We've been doing a lot of refactoring work so that SAFECode can be
used without DSA and Automatic Pool Allocation (APA) and could
therefore be integrated into LLVM and Clang. Integrating them would
make them easier to use (because one wouldn't need to change
Makefiles in large projects to generate bitcode files; just flip a
switch on the Clang command-line) and would ease our maintenance
burden (because there would be less out-of-tree code). An optional,
out-of-tree libLTO library including DSA and APA could provide the
remaining optimization functionality for those that want to use it.<br>
<br>
Would there be any objections to incorporating portions of SAFECode
free of DSA/APA dependencies into mainline LLVM and adding a
command-line option to Clang to tell it to instrument a program
using SAFECode?<br>
<br>
-- John T.<br>
<br>
<blockquote
cite="mid:BANLkTi=SSetML4Nw3ES8qi3c6eLprSg6Zg@mail.gmail.com"
type="cite"><span class="Apple-style-span" style="border-collapse:
collapse; font-family: arial,sans-serif; font-size: 13px;">
<div><br>
</div>
<div>Would the LLVM community be interested in adopting this
code into the LLVM trunk? </div>
<div>
The instrumentation pass is ~350 LOC (<a
moz-do-not-send="true"
href="http://code.google.com/p/address-sanitizer/source/browse/trunk/llvm/AddressSanitizer.cpp">http://code.google.com/p/address-sanitizer/source/browse/trunk/llvm/AddressSanitizer.cpp</a>),
but may grow over time as we add optimizations. </div>
<div>The run-time library (malloc replacement, <a
moz-do-not-send="true"
href="http://code.google.com/p/address-sanitizer/source/browse/trunk/asan/asan_rtl.cc">http://code.google.com/p/address-sanitizer/source/browse/trunk/asan/asan_rtl.cc</a>)
is ~1500 LOC. </div>
<div><br>
</div>
<div>Thanks, </div>
<div><br>
</div>
<div>--kcc </div>
</span>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a class="moz-txt-link-freetext" href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
</blockquote>
<br>
</body>
</html>