LLVM Valgrind

Hi:

I have been working on Valgrind [porting it to non-supported architectures] and wanted to know what you guys think of Valgrind for LLVM.
I haven’t thought through fully myself - so wanted to get your inputs before becoming rigid in my own opinion.

Original Valgrind works on object code - translating the asm to its own IR [intermediate representation]. But for LLVM, probably putting the valgrind
tool instrumentation [e.g. memcheck] as a pass [[i.e. using LLVM IR itself] probably make more sense…

cheers
J.

Javed Absar wrote:

Hi:

I have been working on Valgrind [porting it to non-supported architectures] and wanted to know what you guys think of Valgrind for LLVM. I haven't thought through fully myself - so wanted to get your inputs before becoming rigid in my own opinion.

Original Valgrind works on object code - translating the asm to its own IR [intermediate representation]. But for LLVM, probably putting the valgrind tool instrumentation [e.g. memcheck] as a pass [[i.e. using LLVM IR itself] probably make more sense....

We have done just that in the SAFECode project (http://safecode.cs.illinois.edu). To be more accurate, we took the old SAFECode research code, simplified it a bit (its more advanced features have experienced some bitrot; fixing that is on my TODO list), and enhanced it to use LLVM debugging information to report when a memory safety violation occurs.

SAFECode is a bit like a combination of Valgrind's memcheck and exp-ptrcheck tools in that it checks array indexing operations as well as loads and stores. Additionally, SAFECode's array checking should be more accurate that Valgrind's because LLVM passes can determine the start address and size of stack objects and globals accurately whereas Valgrind's ptrcheck tool has to rely upon heuristics to determine this information. SAFECode is also faster since it can employ static analysis and does not do dynamic binary translation.

All of that said, Valgrind is a much more mature piece of software. Optimization can weaken SAFECode's ability to provide good debug info when used with LLVM 2.6, and testing with LLVM 2.7's improved debug info API isn't done yet. Valgrind is also easier to use; SAFECode currently requires whole-program analysis, which means that you have to use it either on an LLVM bitcode file or through link-time optimization.

If you're interested in SAFECode, please feel free to try it out. SAFECode works with LLVM 2.6 and LLVM 2.7 (although the 2.7 support needs some improvement yet). We have a mailing list (SAFECode: Mailing Lists) to which you can post questions.

-- John T.