<div dir="ltr"><div>Hi Nuno,<br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 22 May 2016 at 22:33, Nuno Lopes <span dir="ltr"><<a href="mailto:nunoplopes@sapo.pt" target="_blank">nunoplopes@sapo.pt</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Pierre,<br>
<br>
I'm the author of the BoundsChecking pass.<br></blockquote><div><br>Wow, I am happily surprised to have an answer from you directly!<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
It's true there's little documentation about it (only mentioned in: <a href="http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#availablle-checks" rel="noreferrer" target="_blank">http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#availablle-checks</a>). You can run it with 'clang -fsanitize=bounds' or 'opt -bounds-checking'.<br>
The BoundsChecking pass, AddressSanitizer and BaggyBoundsCheck are all different code bases, each exploring a different set of tradeoffs.  The goal of the BoundsChecking pass was that the runtime penalty should be low enough to enable usage in production.<br>
<br>
Some information about the BoundsChecking pass:<br>
- It is intra-procedural only. If you dereference a pointer that was passed as argument, then it is not checked (with some exceptions).<br>
- It supports heap allocations, provided that these allocations are done using 1) standard functions that LLVM recognizes (malloc, new, strdup, etc) or 2) functions are annotated with alloc_size (<a href="https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html" rel="noreferrer" target="_blank">https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html</a>)<br>
- It's helpful to compile with -O2, otherwise the pass will get confused very quickly.  The design of the analysis assumes at least a few simplifications were done before.<br></blockquote><div><br></div><div>OK, I just compiled it with -O2 and the heapoverflow protection have been triggered. Though, I don't know what is the simplification required for the pass to run correctly?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- Sometimes LLVM transforms loops into intrinsics, like memcpy or memset. Right now these are not checked (but should, though)<br>
- Guards are mostly not hoisted out of loops by LLVM; this needs improvement otherwise perf may suffer quite a bit.<br></blockquote><div><br></div><div>Are you still working on it? If yes, what is it that you are trying to do? I would like to work on this Pass during summer (until end of August). That would be great if you could lead me a little bit =)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- The analysis code is in lib/Analysis/MemoryBuiltins.cpp<br></blockquote><div><br></div><div>I have a question on this. As I read the code I was wondering how the run-time part was implemented. I was looking for something like a redefinition of malloc&free functions but I found no clue. Now I'm wondering if it's reduced to the run-time action of the ObjectSizeOffsetEvaluator class? This one is used to get the size&offset of the current array pointer.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Hope this helps. Please let us know if you have more questions.<br></blockquote><div><br></div><div>This already helped a lot, thank you!<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Nuno<br></blockquote><div><br></div><div>Pierre</div></div><br></div></div></div></div>