search for: boundschecking

Hi, I am a final year French student doing an internship at the University of Portsmouth. As I was taking hands on AddressSanitizer I took a look at BoundsChecking (both are in the lib/Transforms/Instrumentation folder). I found nothing on it except for the LLVM Documentation and references to BaggyBoundsCheck (which is not the same project. As far as I understood it is part of the SAFECode project). Does anyone knows about it (BoundsChecking)? I have some i...

Hi Pierre, I'm the author of the BoundsChecking pass. It's true there's little documentation about it (only mentioned in: http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#availablle-checks). You can run it with 'clang -fsanitize=bounds' or 'opt -bounds-checking'. The BoundsChecking pass, AddressSanitizer and B...

Hi Nuno, On 22 May 2016 at 22:33, Nuno Lopes <nunoplopes at sapo.pt> wrote: > Hi Pierre, > > I'm the author of the BoundsChecking pass. > Wow, I am happily surprised to have an answer from you directly! > It's true there's little documentation about it (only mentioned in: > http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#availablle-checks). > You can run it with 'clang -fsanitize=bounds...

Hello everyone, I have noticed that there is a BoundsChecking.c under lib/Transforms/Instrumentation/. I am wondering how to use this tool and which type of bugs it targets. Are the tool provide the same functionality with Address Aanitizer? Thanks a lot -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org...

...on, but it may have been fixed in the meantime. There are still 3 jumps, though. Nuno ----- Original Message ----- From: "Schoedel, Kevin P" <kevin.p.schoedel at intel.com> To: <llvmdev at cs.uiuc.edu> Sent: Monday, November 26, 2012 3:56 PM Subject: [LLVMdev] RFC: change BoundsChecking.cpp to use address-based tests >I am investigating changing BoundsChecking to use address-based rather > than size- & offset-based tests. > > To explain, here is a short code sample cribbed from one of the tests: > > %mem = tail call i8* @calloc(i64 1, i64 %elements) >...

I am investigating changing BoundsChecking to use address-based rather than size- & offset-based tests. To explain, here is a short code sample cribbed from one of the tests: %mem = tail call i8* @calloc(i64 1, i64 %elements) %memobj = bitcast i8* %mem to i64* %ptr = getelementptr inbounds i64* %memobj, i64 %index %4 = load i6...

Hi everyone, I am having troubles but this shouldn't be hard to solve for many people here. I am beginning a runtime feature for the BoundsChecking pass and I want to replace the libc malloc&free. I followed the design of AddressSanitizer (Asan) and tried to use the INTERCEPTOR macro from the interception.h file of compiler-rt library. Here is the problem. The file I modify (BoundsCheking.cpp) is in lib/Transforms/Instrumentation/ and I c...

Hi, > Could you provide a bit of background of the expected domains of Size and > Offset? In particular, are they signed or unsigned integers? A > non-negative size doesn't seem to make much sense in this context, but > depending on how it's calculated I could see it arising. Is a zero Size > something that might arise here? I'm assuming the Offset comes from an

Nuno, Inspired by this email thread, I spent a bit of time today looking through the implementation of BoundsChecking::instrument(..). Based on my reading of prior work, it should be possible to do these checks in two comparisons, or possibly even one if the right assumptions could be made. Could you provide a bit of background of the expected domains of Size and Offset? In particular, are they signed or un...

On Wed, 30 May 2012 10:04:50 -0700 Andrew Trick <atrick at apple.com> wrote: > Originally on llvm-commits. > > On May 30, 2012, at 8:48 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > >> This is probably fine for now. It's a relatively safe use of > >> SCEVExpander and the least effort approach, but generally I would > >> like to encourage

Originally on llvm-commits. On May 30, 2012, at 8:48 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote: >> This is probably fine for now. It's a relatively safe use of SCEVExpander and the least effort approach, but generally I would like to encourage people to solve local rewrite problems with IRBuilder, not SCEVExpander, and build useful utilities for that purpose. Just because you

> On May 25, 2016, at 6:05 AM, Pierre Gagelin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi everyone, > > I am having troubles but this shouldn't be hard to solve for many people here. I am beginning a runtime feature for the BoundsChecking pass and I want to replace the libc malloc&free. I followed the design of AddressSanitizer (Asan) and tried to use the INTERCEPTOR macro from the interception.h file of compiler-rt library. > > Here is the problem. The file I modify (BoundsCheking.cpp) is in lib/Transforms/Instrumentatio...

John, Many thanks for your prompt reply! You think it a better idea than a new implementation of bounds overflow checking, that integrating previous work such as this: http://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.html into current LLVM. Yes? 在 2010年3月31日 下午12:11，John Regehr <regehr at cs.utah.edu>写道： > Hi Qiuping, > > I don't know much about SAFECode, you should

...it any different than what SAFECode, SoftBound, or ASan do? Regards, John Criswell On 5/25/16 8:05 AM, Pierre Gagelin via llvm-dev wrote: > Hi everyone, > > I am having troubles but this shouldn't be hard to solve for many > people here. I am beginning a runtime feature for the BoundsChecking > pass and I want to replace the libc malloc&free. I followed the design > of AddressSanitizer (Asan) and tried to use the INTERCEPTOR macro from > the interception.h file of compiler-rt library. > > Here is the problem. The file I modify (BoundsCheking.cpp) is in > lib/Tr...

...ed at was BaggyBoundsCheck which is an object based memory protection. In this way it still allows wild accesses inside an allocation - I quickly looked at SoftBound and it does protect the memory at a precise level. However metadata is separately stored which involve higher overhead My point is BoundsChecking has been designed (by Nuno Lopes) to be a very low overhead checking tool. For the moment no runtime have been implemented and I wanted to do a lightweight one on it (I am just a student so even for the personal experience I'm interested). The runtime would be necessary to solve the actual prob...

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. John On Tue, 30 Mar 2010, ??? wrote: > > Hi, > > Some days ago I am interested in detecting undefined behaviors > > in C

Hi everyone, After spending 2 months on LLVM generally speaking and more specifically on security passes (ASan, SAFECode, BoundsChecking) I wanted to know if there were an available implementation of strictly fat-pointer based approach to enforce bounds? If not, I wanted to implement one. I think it is interessant to have such a tool available even if there are better designs (SoftBound does have a fat-pointer approach with separat...

...uld be "Debug > +ExpensiveChecks" not "Debug-ExpensiveChecks". Ok. Is "ExpensiveChecks" a reasonable keyword for this? I wanted something that could encompass other things people might want without creating thousands of build combinations and Debug+CxxLibChecks+BoundsChecking+ElectricFence+Even+More+ Things+That+Would+Create+Ridiculously+Long+Build+Names I wanted to keep things at least mostly sane. -Dave

...re the two existing tools with the new one. Earlier you wrote: >> So the main idea of this new flag is not for debugging, but rather for production. >> This means that we won't be able to perform as many checks as >> AddressSanitizer, >From the code (lib/Transforms/Scalar/BoundsChecking.cpp) I can conclude that you add checks only if you can deduct the array boundaries, either from constants or from malloc() parameter. How many run-time checks does -fbounds-checking create? Do you have such statistics? Do you also have performance numbers? Are there any bugs that -fbounds-checkin...

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