similar to: GSoC and SAFECode

Dear Michael, If you're interested in SAFECode, the first step is to get SAFECode working with a newer version of LLVM. A Master's student did some work on this last summer with LLVM 3.7 but didn't finish. It would now need to be updated to LLVM 3.8 (though I suppose a completed LLVM 3.7 port would be fine with me). After that, there are some interesting projects on which to

John Criswell wrote: > If you're interested in SAFECode, the first step is to get SAFECode > working with a newer version of LLVM. A Master's student did some > work on this last summer with LLVM 3.7 but didn't finish. It would > now need to be updated to LLVM 3.8 (though I suppose a completed LLVM > 3.7 port would be fine with me). > > After that, there are

Abstraction ---------------------------------- This projects will enhance the ‘Baggy Bounds with Accurate Checking’ [1] work. I will provide more efficient runtime checks in BBAC framework by adding more informations to the memory object’s padding area. A new padding area scheme will be designed to make these informations compact and efficient to fetch. I will create some new runtime checks on

First of all, I am really sorry about my time scheduling. I did not manage to upload my proposal at the last minutes before Google Summer of Code submission deadline. Could you kindly take the following revision as my final proposal? Abstraction --------------------- This projects will enhance the ‘Baggy Bounds with Accurate Checking’ (BBAC) [1] work. By adding information to the memory object’s

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

Dear LLVM and SVA community: This is to brief you the progress of this week. I mainly focused on minor fixes this week. Following is what I finished this week. 1. Move the implementation of runOnModule of RegisterGlobalVar pass from .h back to .cpp file. 2. Introduce two new functions to register and unregister function prototypes on llvm.compiler.used. 3. Added two regression tests for

Hi， John Criswell！ You have said to me that SAFECode had not been maintained for several years, 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:

Dear LLVM developers: Here is my another proposal of LLVM. Any suggestion would be welcome! * ** * *** Integrate Baggy Bounds Checking into SAFECode*** * * *Abstract:** * Baggy Bounds Checking (BBC) is an efficient bounds checking technique that pad and align objects to powers of two and enable allocation bounds. It uses a contiguous array as bounds table to enable

Please create a similar branch for Klee; I've been working on porting that to 2.7 as well.<br /> <br /> Best, Erich Ocean<br /> <br /> On Fri, Mar 5, 2010 at 8:43 PM, John Criswell (criswell@uiuc.edu) wrote:<br /> > <br /> > Dear SAFECoders and LLVMers,<br /> > <br /> > There is some new work on moving DSA to the new LLVM 2.7 API.

On 2/26/15 9:54 AM, Jyoti Rajendra Allur wrote: > Hello All, > I am looking at exploring what benefits SAFECode has to offer over clang S.A and llvm's instrumentation tools like memory sanitizer and address sanitizer. Are you looking for an off-the-shelf tool, or are you looking for approaches to use in your own tool? > I could come up with the following that are not provided in

John, The release source code (sc-main.tar) won't compile cleanly under Debian6-i386 (gcc/g++: 4.4.5). The compiler back trace is attached. Please fix it/them and repost. Or, 64b system is a requirement? Thank you Chuck llvm[4]: Compiling TypeRuntime.cpp for Release+Asserts build (PIC) cc1plus: warnings being treated as errors

Hi, My apologies for the trouble. I've disabled building DynamicTypeChecks for now (r138224) and now it builds cleanly on 32bit for me here. As for SAFECode support for 32bit vs 64bit, I believe 32bit should work just fine although I haven't personally tested this. Let me know if you have any further issues/questions. ~Will On Sun, Aug 21, 2011 at 9:26 AM, Chuck Zhao <czhao at

Dear All, We now have two new mailing lists for SAFECode: 1) svadev: This mailing list is for discussion on SAFECode. Questions and comments about using SAFECode as well as development conversation on SAFECode can go here. 2) sva-commits: This mailing list gets email for all SVN commits made to SAFECode. -- John T.

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. . I found most of the projects quite alluring as I have been working on a

Török Edwin wrote: > [snip] > > I applied the attached patch to make it compile on my box (Debian > x86_64), only to find out that x86_64 is not supported :( > This architecture is not supported by the pool allocator! > Aborted > Thanks for the patch. What options do I give to the patch command to apply it to the source code? Although there's no documentation about

Thank you all for the responses, John, My Bad here you go clang version 3.2 (trunk) Target: i386-pc-linux-gnu Thread model: posix [root at localhost opensrc]# cat /etc/centos-release CentOS release 6.2 (Final) Matthieu, Thanks for the fix and let me try again with latest trunk. ~Umesh On Mon, May 14, 2012 at 10:34 PM, Matthieu Monrocq <

Hi John, That worked for me. I am using llvm 3.2 only and following http://safecode.cs.illinois.edu/docs/Install.html So for I am able to make inside llvm/projects/poolalloc by doing such cosmetic changes. Now, when I tried to make inside llvm/projects/safecode, I see another error. kpawar at KPAWAR-LT ~/SAFECode/LLVM_SRC/llvm/projects/safecode $ /usr/bin/clang -cc1 -triple

On 5/14/12 4:32 AM, Umesh Kalappa wrote: > Hi All , > > Was trying to build the LLVM src from > http://llvm.org/svn/llvm-project/llvm/branches/release_30 ,But unable > to build the same and clang poped up with below error . First, it sounds like you're building LLVM 3.0, Poolalloc, and SAFECode with an unmodified version of clang. Is this correct? If so, which version of

On Mon, May 14, 2012 at 4:39 PM, John Criswell <criswell at illinois.edu>wrote: > On 5/14/12 4:32 AM, Umesh Kalappa wrote: > > Hi All , > > Was trying to build the LLVM src from > http://llvm.org/svn/llvm-project/llvm/branches/release_30 ,But unable to > build the same and clang poped up with below error . > > > First, it sounds like you're building LLVM

Hello All, I am looking at exploring what benefits SAFECode has to offer over clang S.A and llvm's instrumentation tools like memory sanitizer and address sanitizer. I could come up with the following that are not provided in ASAN/MSAN/Clang S.A -> dangling pointer error and detection -> crashes in system libraries due to security vulnerabilities. In the process, I wanted to run the