[LLVMdev] Re: Re: summer of code idea― update the SAFECode project to the new LLVM API

Wed Apr 7 17:21:36 PDT 2010

Hi, John Criswell!

Thank you for your detailed and fast reply.
I will update my proposal following your suggestion as soon as possible.

Best Regards!
Qiuping

2010-04-08 

yiqiuping1986 

发件人： John Criswell 
发送时间： 2010-04-07  23:57:29 
收件人： yiqiuping1986 
抄送： llvmdev 
主题： Re: summer of code idea― update the SAFECode project to the new LLVM API 

yiqiuping1986 wrote:
> Hi， John Criswell！
> You have said to me that SAFECode had not been maintained for several
> years,
Just to clarify, SAFECode *has* been and *is* maintained (primarily by
me). The release_26 branch in the SVN repository works with LLVM 2.6,
and mainline is working (with some regressions) with the upcoming LLVM
2.7. You can subscribe to the SVA Commits mailing list
(http://lists.cs.uiuc.edu/mailman/listinfo/sva-commits) to get email
whenever a commit is made to SAFECode.
However, there is an inter-procedural static array bounds checking pass
that comprises a small component of SAFECode. It is an optional
component, so SAFECode works without it, but SAFECode would work better
if this static array bounds checking pass were working.
This inter-procedural static array bounds checking pass in SAFECode has
not been maintained and needs to 1) be updated to work with LLVM
2.6/2.7; 2) have its bugs fixed; and 3) improved so that it has better
performance (i.e., no repeated fork()/exec() for constraint solving).
> now I have submitted my proposal for updating the SAFCode project to
> the new LLVM APIs.
> If you are still interested in the topic and willing to guid my
> project, I will be very happy.
> Now I'm waiting for you comments.
> Here is my proposal:
> http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/easyqiu/t127038894856
Looking back at my previous email, I see that I was unclear. SAFECode,
as a whole, is up-to-date with LLVM. However, it is missing its static
array bounds checking pass (because that specific pass has not been
maintained). What I was suggesting is that, as a GSoC project, you could
update the static array bounds checking code from the SAFECode project.
With that in mind, here is what I think you should do:
1) Update your "Check bounds overflow bugs in C programs based on LLVM"
proposal
(http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/easyqiu/t126993884556).
In it, state that
a) you are specifically interested in implementing *static* array bounds
checking
b) there is old code in the SAFECode project which you may reuse to
build your static array bounds checking pass
c) you will investigate whether any of the static array bounds checking
code in SAFECode is useful. If it is, you can reuse it. Otherwise, you
will develop something new.
d) remove the comment about Edwin Torok's pass being intra-procedural.
He has told us (or at least me) that his analysis is inter-procedural.
e) you can list me as a potential mentor, if you like.
2) Delete the "Update the SAFECode project to the new LLVM API"
proposal. SAFECode, as a whole, works with LLVM 2.6/2.7. Reusing the old
static array bounds checking pass from SAFECode can be merged into your
bounds checking proposal (as I stated above).
3) In all of your proposals, you should state why the mentor would be a
good mentor. In my case, you can state that I am a past LLVM contributor
and that I am the primary maintainer of the SAFECode project (which uses
LLVM extensively).
4) In your ABCD proposal, did you copy the text describing the ABCD
algorithm from the ABCD paper? If so, don't do that; describe the
algorithm in your own words (even if your English isn't perfect). It
will show that you understand the algorithm and prevent you from being
accused of plagiarism.
5) Cite sources. If your proposal states that you are going to implement
an algorithm described in a paper, specify exactly which paper it is.
That way, the proposal reviewer can look at the paper.
-- John T.
> 2010-04-07
> ------------------------------------------------------------------------
> yiqiuping1986
> ------------------------------------------------------------------------
> *发件人：* John Criswell
> *发送时间：* 2010-03-30 22:42:53
> *收件人：* John Regehr
> *抄送：* 易秋萍; llvmdev at cs.uiuc.edu
> *主题：* Re: [LLVMdev]summer_of_code_idea_―_checking_bounds_overflow_bugs
> John Regehr wrote:
> > Qiuping,
> >
> > Have you looked at what has already been done? I would expect that
> taking
> > previous work such as this:
> >
> > http://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.html
> >
> > and integrating into current LLVM would be a better idea than starting
> > over.
> >
> This code is publicly available from the SAFECode project (see
> http://safecode.cs.illinois.edu to see how to get it). However, it has
> not been maintained well over the years and is currently disabled.
> Getting it to work again with LLVM 2.6 or replacing it with something
> better would be nice.
> I'm writing up a response to this project idea as I'm willing to mentor
> it; I'll send it out shortly.
> -- John T.
> > John
> >
> >
> > On Tue, 30 Mar 2010, ??? wrote:
> >
> >
> >> Hi,
> >>
> >> Some days ago I am interested in detecting undefined behaviors
> >>
> >> in C programs based on Clang. After several days? investigation, I
> think
> >>
> >> checking bounds overflow bugs is more interesting, because bounds
> >>
> >> overflow is one of the most frequently encountered errors in C
> programs.
> >>
> >> For example, performing pointer arithmetic without checking bounds
> >>
> >> can cause bounds overflow. To increase the accuracy of finding bugs,
> >>
> >> I want to write several passes, based on slicing, inline and summary
> >> function
> >>
> >> / (partial) transition function, to implement intre-procedural
> analysis.
> >>
> >> Does some person have interest in the project? I need a mentor,
> >>
> >> and wait for your reply.
> >>
> >>
> >>
> >> Best Reagards!
> >>
> >>
> >>
> >> Qiuping Yi
> >>
> >>
> >>
> > >
> _______________________________________________
> 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/20100408/7e469e59/attachment.html>