similar to: [LLVMdev] GSoC 2012 proposal : Integrate Baggy Bounds Checking into SAFECode

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

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

Hello all, Here is my GSoC 2012 proposal: Python bindings for LLVM. Any feedback are welcome! *Title: Python bindings for LLVM* *Abstract: * llvm-py provides Python bindings for LLVM. The latest llvm-py supports bindings with Python 2.x version for LLVM 2.x. This project is to improve llvm-py to make it compatible with both Python 2.x and Python 3 for LLVM 3. *Motivation* LLVM is used as a

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

Hello all, I found that the alignment for stack value has no limitation, but for global value, it has a limitation. Here is an example: #include <stdio.h> #include <stdlib.h> char x[4000] __attribute__((aligned(4096))); int main (int argc, char ** argv) { char y[4000] __attribute__((aligned(4096))); printf("x is %p\n", x); printf("y is %p\n", y); return

Hi, everyone. I'm a senior at Swarthmore College and would love to work with LLVM this summer. I'm interested in systems languages and security, and I'll start a PhD on these topics this fall. I also do a good deal of open source development and auditing with OpenBSD and a variety of other projects. I spent last year's GSoC doing security auditing for Pidgin/libpurple. GSoC seems

On 3/30/12 1:08 PM, Raphael Ernani Rodrigues wrote: > Dear LLVMers, > > My name is Raphael Ernani, and I am doing my MsC at the Federal > University of Minas Gerais, Brazil. I have been using LLVM for a > while, and I would like to participate in this year's Summer of Code. > One particular idea, in your "open projects" page caught my eye, and I > decided to

Dear LLVMers, We are happy to announce an alpha release of the SAFECode compiler. It is now available for download from the LLVM public Subversion repository. SAFECode uses a set of analysis passes and program transformations to provide strong memory safety guarantees to C/C++ programs. Specifically, the safety guarantees are: o Array bounds checking (prevents pointers from overflowing

On 8/14/12 12:19 PM, John McCall wrote: > On Aug 14, 2012, at 7:31 AM, Baozeng wrote: >> Hello all, >> I found that the alignment for stack value has no limitation, but for global value, it has a limitation. Baozen, with what version of LLVM did you do the following test? Was it LLVM mainline? >> >> Here is an example: >> >> #include <stdio.h>

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.

Dear SAFECoders and LLVMers, There is some new work on moving DSA to the new LLVM 2.7 API. I am hoping to do something similar for SAFECode once the code freeze occurs. To keep things running smoothly, there are now release_26 branches for the poolalloc and safecode projects. If you are using SAFECode, Poolalloc, or DSA with LLVM 2.6, you will want to switch to these branches. To get

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.

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

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

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

John, We (more accurately, John Criswell and Brice Lin) are working on a debugging version of SAFECode right now, which should be robust enough to play with soon. What kinds of embedded codes do you have in mind? One of our goals has been to minimize or even eliminate run-time checks for embedded code that meets certain restrictions. You can see the following paper for more details:

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

Hi John, > We have a new release of Clang with SAFECode technology for detecting > memory safety errors. Memory safety checking (SAFECode for short) can be > turned on with a single command line switch to clang/clang++. The > SAFECode techniques do not change the behavior of the clang/clang++ > compilers in any way when the switch is turned off, so this can be used > as a