similar to: [LLVMdev] generate ponter/array access bounds expressions

Hello, I want to generate pointer/array access bounds expressions within LLVM. I have read some docs about symbolic and KLEE, but I am not sure if there are some better methods. I guess it is possible to do it with symbolic execution[1]， but I think it is a little complex to do my project with klee. It seems I need to do some work like in [1] to KLEE to finish my project. And I wonder if

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.

Hi all, Greetings. I'm a Ph.D. student in UIUC. Now I'm working on SAFECode, a research compiler based on LLVM which insert necessary runtime checks to guarantee memory-safety of programs. SAFECode needs to insert checks into the programs (say, please check this load instruction for me). Currently SAFECode inserts these checks as normal call instructions. It would be great that LLVM can

On Fri, Apr 6, 2012 at 7:50 AM, John Criswell <criswell at illinois.edu> wrote: > On 4/6/12 12:50 AM, Kostya Serebryany wrote: > > I'd like some similar work to be done, although I view it a bit > differently. > This might be a separate analysis pass that knows nothing about ASAN or > SAFECode > and appends metadata nodes to memory access instructions saying things

Dear All, Just a reminder that the maintenance will be commencing now. -- John T. John Criswell wrote: > Dear LLVMers and Clangers, > > We'll be doing some maintenance on the LLVM repository on Tuesday, Sept. > 14 (tomorrow). There were some files committed to the repository that > we believe need to be removed from both mainline, the branches, and the > revision

I'd like some similar work to be done, although I view it a bit differently. This might be a separate analysis pass that knows nothing about ASAN or SAFECode and appends metadata nodes to memory access instructions saying things like - this access can not go out of buffer bounds - this access can not touch free-ed memory - this access can not participate in a race - this read

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

Dear LLVMers and Clangers, We'll be doing some maintenance on the LLVM repository on Tuesday, Sept. 14 (tomorrow). There were some files committed to the repository that we believe need to be removed from both mainline, the branches, and the revision history. The SVN repository will go *off-line* at 7:00 am Central Daylight Savings time on Tuesday. Please do not make any commits after

This is a proposal to create memory safety instrumentation and optimization passes for LLVM. Abstract: The goal of this project is to modify SAFECode and AddressSanitizer (ASAN) to use a common set of memory safety instrumentation and optimization passes to increase code reuse. These tools and other similar ones use varying methods to detect whether memory accesses are safe, but are fundamentally

On Oct 11, 2011, at 3:02 PM, Daniel Dunbar wrote: > If the community thinks this is an important problem for LLVM to > address, then I think the ideal solution is that we provide a set of > autoconf/makefile/whatever foo that uses llvm-config and so on, but > doesn't try and do things like include the LLVM Makefiles or the LLVM > autoconf files. This would also provide a

Ok, based on the responses on this thread I'm going to change my plan a bit. I didn't expect that that many people were using the existing set up. I still want to deprecate the current sample setup which is intimately tied in with LLVM's own build system (so that we are more free to make changes to how the project itself builds). However, I will plan on doing this by refactoring the

On 4/6/12 12:50 AM, Kostya Serebryany wrote: > I'd like some similar work to be done, although I view it a bit > differently. > This might be a separate analysis pass that knows nothing about ASAN > or SAFECode > and appends metadata nodes to memory access instructions saying things > like This is a good idea but is the wrong way to implement the idea. LLVM passes are

Sounds an good idea, is that means lowerinng down the SAFECode project from the higher level(clang)to lower level for an more general work on bound check? I aslo want to know is it possoble to detecting memory leak at the very low(llvm ir) level to detecting memory leaks? Or at llvm ir level to providing an stackfull hooks? It's very useful to have such an feature. The stack hooks can help us

Hi John, I knew I would hear from you. :) On Tue, Oct 11, 2011 at 2:38 PM, John Criswell <criswell at illinois.edu> wrote: > On 10/11/11 3:24 PM, Daniel Dunbar wrote: >> >> Hi all, >> >> I would like to deprecate the LLVM project's "official" support of >> setting up the Makefiles / autoconf configurations in such a way that >> external

Hi, I commit my proposal titled �Maintain the Array Bound checking pass of the SAFECode Project�. Wellcome your comments, if you are interested in the topic. My proposal URL is http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/easyqiu/t127038894856 2010-04-08 yiqiuping1986 -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Tue, Oct 11, 2011 at 11:49 PM, Anna Zaks <ganna at apple.com> wrote: > On Oct 11, 2011, at 3:02 PM, Daniel Dunbar wrote: >> If the community thinks this is an important problem for LLVM to >> address, then I think the ideal solution is that we provide a set of >> autoconf/makefile/whatever foo that uses llvm-config and so on, but >> doesn't try and do things

易秋萍 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

Adve, Vikram Sadanand wrote: > On Mar 30, 2010, at 11:33 AM, John Regehr wrote: > > >> John-- a couple questions: >> >> Can you explain the SAFECode model in a bit more detail? I am getting >> conflicting information. On one hand, some of the papers describe a >> system that is primarily designed to hide safety violations. On the other >> hand,

On Mar 30, 2010, at 11:33 AM, John Regehr wrote: > John-- a couple questions: > > Can you explain the SAFECode model in a bit more detail? I am getting > conflicting information. On one hand, some of the papers describe a > system that is primarily designed to hide safety violations. On the other > hand, the 2006 ICSE paper that I cited earlier today seems to be talking

Hi John- Will this also mean a purging of the llvm-commits archive, to remove the diffs with the guilty files in them? Alistair On 14 Sep 2010, at 01:38, John Criswell wrote: > Dear LLVMers and Clangers, > > We'll be doing some maintenance on the LLVM repository on Tuesday, Sept. > 14 (tomorrow). There were some files committed to the repository that > we believe need to