[llvm-dev] [GSoC16] Seeking Guidance for a project regarding SAFECode

[John Criswell via llvm-dev]

On 3/3/16 12:25 PM, Abhinav Tripathi via llvm-dev wrote:
> Hello,
> I am Abhinav Tripathi, B.Tech 3rd Year student from IIT Indore, India. 
> I was looking on the projects ideas page of llvm and saw that I could 
> also propose to work on the SAFECode Open projects. As I found no 
> mailing list on their site, I am sending this message here. Please 
> redirect me to some other list, if required.

The most useful project for SAFECode right now is to update its code to 
work with either LLVM 3.7 or LLVM 3.8.  I had a student work on this 
last summer (code is at https://github.com/jtcriswell/safecode-llvm37), 
but it needs to be completed and tested.  On my end, I'm interested in 
getting SAFECode dusted off because I'd like to use it for research 
projects that need to attach metadata to memory objects.

Until SAFECode is updated to a newer version of LLVM, its utility is 
pretty limited, and any projects to enhance it will basically require 
that it be updated to a newer version of LLVM.

> .
> I found most of the projects quite alluring as I have been working on 
> a similar project (in terms of tasks) since the last GSoC. It is 
> CPPSharp (https://github.com/genuinelucifer/CppSharp).
> .
> The ones that I found most interesting were:
> 1 - Improve Static Array Bounds Checking -- Because I have done a lot 
> of array related tasks while writing marshalling code for CppSharp. I 
> think I can really contribute into this project.

Static Array Bounds Checking requires that you understand static 
analysis.  Multiple static analysis methods are applicable: range 
analysis, integer linear programming, SMT solvers, etc.  For a 
successful proposal for static array bounds checking, you should know 
which algorithm you will implement and be able to explain why you think 
it will work well.  For SAFECode, the algorithm must be sound with 
respect to two's complement arithmetic (i.e., the algorithm must take 
into account that integers in C can experience underflow or overflow 
when used in arithmetic).

> .
> 2 - Create a simpler CompleteChecks pass -- Although I admit, I didn't 
> quite understand what simpler would mean here. But it seems fairly 
> challenging (if it's regarding optimisation) or involving 
> understanding of a large part of codebase (in which case too it 
> intrigues me). I would love to work on this one too.

The CompleteChecks pass currently uses the DSA points-to analysis (which 
is large and complicated).  There are simpler analyses that one could do 
to determine whether a memory object is read or written by external 
code.  For example, a simple intra-procedural analysis could determine 
if a memory object is allocated and only used by the current function, 
and a simple inter-procedural analysis could create a very simple heap 
abstraction and perform data-flow analysis on the pointers contained 
within heap objects to determine if they are influenced by external 
library code.  Basically, there are some simple quick analyses that 
would be imprecise but could probably find memory objects that are not 
manipulated by external code.

> .
> If the mentor(s) or anyone else would like to state a few proficiency 
> tests to prove my aptness for the projects, I would love to submit a 
> couple of patches before applying for GSoC.

I think the only proficiency test is whether you can show in your 
proposal that you have the necessary programming skills and background 
information to be able to do what you propose.  In both of these 
projects, if you're not familiar with static analysis (e.g., Kam/Ulman 
data-flow analysis), then you're likely not ready for these projects.  
For the two projects you mentioned, I would also expect existing 
familiarity with LLVM.

Again, though, the best project is probably to update SAFECode to a 
modern version of LLVM.

Regards,

John Criswell

> .
> Regards,
> Abhinav
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


-- 
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
http://www.cs.rochester.edu/u/criswell

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160316/bc27e6c5/attachment.html>