Svadev mailing list

[John Criswell <criswell AT illinois.edu>]

On 4/22/13 9:12 AM, Baozeng wrote:

Hello John,

2013/4/18 John Criswell <criswell AT illinois.edu>

On 4/17/13 8:18 PM, Baozeng wrote:

Hi John,

    Cling ( http://root.cern.ch/drupal/content/cling) is  an interactive C++ interpreter, built on the top of LLVM and Clang libraries. Currently when a memory error happens, Cling will trap a segmentation fault. For instance:

[cling]$ extern "C" int printf(const char* fmt, ...);

[cling]$ class MyClass { [cling]$ ?  private: [cling]$ ?     int a; [cling]$ ?   public: [cling]$ ?      MyClass() : a(1){} [cling]$ ?   int getA(){return a;} [cling]$ ?   }; [cling]$ MyClass* my = 0; [cling]$ my->getA() Segmentation fault (core dumped)

   We want to improve Cling by detection such NULL pointer dereference errors. The expected results should be as the following:

[cling]$ my->getA() warning: you want to dereference a NULL pointer. do you still want to proceed?[y/n]

If all you want is a NULL pointer detector, you can easily write an LLVM pass that does that.

   Since SAFECode ensures memory safety based on LLVM and Clang. We want to link Cling with SAFECode to see whether we can get the expected results. (We also want to improve Cling by detecting other memory error, such as buffer overflow, double free and so on)

   As we know, current SAFECode trunk is based on LLVM 3.2 and a modified version of  Clang 3.2. Cling trunk is based on upcoming LLVM and Clang (which is about version 3.3). So we cannot link Cling with SAFECode directly. Could you tell me are the modifications in Clang that comes in the SAFECode distribution very much?

I'm not sure if it's relevant to cling, but to answer your question, the SAFECode version of clang makes only minor modifications to mainline clang.  The only changes we made were to add additional command line arguments and to run SAFECode passes based on those arguments.

 One way is to  bring SAFECode up to date and then Cling can use it. The other way is that just modify or adapting what we need in Cling. Could you give me some suggestions? Thanks.

I assume that Cling takes C++ code, converts it to LLVM IR, and then uses LLVM passes to optimize it and generate native code.  If that is correct, you could just adapt Cling to run the SAFECode passes that you want.

Cling is able to parse/compile code incrementally. It stores the input as deltas in form of cling::Transaction objects ( http://cling.web.cern.ch/cling/doxygen/classcling_1_1Transaction.html). It uses just-in-time (JIT) compiler for compilation.

Interesting.  Since it uses JIT techniques, whole-program analysis techniques (like type-safe load/store elimination) and potentially time-consuming optimizations may be ill-suited.   You probably want to focus on a technique with a fast run-time check implementation: something like Baggy Bounds, WIT, or the original SAFECode poolchecks (which are buried somewhere in the SAFECode/Poolalloc revision history).

The BBAC code would be my recommendation: it should be fast, it has a simple implementation, and we'd love to have patches that make it more robust.
:)

Regarding plans, I don't think we'll be updating SAFECode to LLVM 3.3 until sometime after July.  Between now and July, we're focusing on making the Baggy Bounds Checking feature more robust in preparation for a funding agency evaluation.

I think your best option is to create your own copy of SAFECode that is updated to LLVM 3.3 and compile cling against that. 

How much efforts  does the updatation need?  A couple of days?

I don't know.  I do not think it would take too long, but it depends on how much LLVM has changed since LLVM 3.2.  Chandler was wanting to change the names of the LLVM libraries and header file paths; that would require changes to the Makefiles and #include's in the source code.

C++ API changes may be less, but I honestly don't know; the point of sticking with a particular LLVM release is to ignore those details until we have the time to deal with them.

-- John T.