Svadev mailing list

[Baozeng <sploving1 AT gmail.com>]

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.

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?

Once we move the SAFECode to LLVM 3.3, you can upstream your changes to the official SAFECode repository.

Just out of curiosity, does Cling follow LLVM trunk, or does it stick with a particular LLVM release for awhile like SAFECode does?

I have no idea. Maybe the cling developer Vassil could answer you this question.

Thanks.

-- John T.

-- 

     Best Regards,
                                                                 Baozeng Ding
                                                                 OSTG,NFS,ISCAS

--
     Best Regards,
                                                                 Baozeng Ding
                                                                 OSTG,NFS,ISCAS

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.

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.  Once we move the SAFECode to LLVM 3.3, you can upstream your changes to the official SAFECode repository.

Just out of curiosity, does Cling follow LLVM trunk, or does it stick with a particular LLVM release for awhile like SAFECode does?

-- John T.

-- 

     Best Regards,
                                                                 Baozeng Ding
                                                                 OSTG,NFS,ISCAS

--
     Best Regards,
                                                                 Baozeng Ding
                                                                 OSTG,NFS,ISCAS