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 http://sva.cs.illinois.edu/downloads.html. 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.
On 8/18/11 10:17 AM, Duncan Sands wrote:> 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.> > Ciao, Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Thu, Aug 18, 2011 at 7:56 AM, John Criswell <criswell at illinois.edu>wrote:> 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> 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 > http://sva.cs.illinois.edu/downloads.html. 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 > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110818/bdc2b25b/attachment.html>
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 On 8/18/2011 10:56 AM, John Criswell wrote:> 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 > http://sva.cs.illinois.edu/downloads.html. 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 > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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 On Sun, Aug 21, 2011 at 9:26 AM, Chuck Zhao <czhao at eecg.toronto.edu> wrote:> 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 > > > > > On 8/18/2011 10:56 AM, John Criswell wrote: >> 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 >> http://sva.cs.illinois.edu/downloads.html. 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 >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Possibly Parallel Threads
- [LLVMdev] Clang + SAFECode Release Announcement
- [LLVMdev] Clang + SAFECode Release Announcement
- [LLVMdev] can't build LLVM under Cygwin | released MinGW llvm-2.3 image
- [LLVMdev] can't build LLVM under Cygwin | released MinGW llvm-2.3 image
- [LLVMdev] still failed to build the llbrowse on Debian5-32b-llvm2.8