[llvm-commits] Specification for Run-time Checks

[Kostya Serebryany]

+Ott Tinn

Some comments, mostly related to asan:

>> lscheck (void * ptr, int length)
length should be size_t
asan needs to distinguish between reads and writes.

>> pool register stack(void * p, int size)
asan needs more information for the stack than just pointer and size.
Currently, there is a extra constant string with frame description.
Asan modifies the whole stack frame at once, not every single alloca
separately.
size must be size_t

>> pool register global(void * p, int size):
This is very slow for cases when we have millions of globals.
asan uses a callback which takes an array of globals as a parameter.
Also, asan modifies the global (adding a redzone at right).
size must be size_t

>> pool unregister(void * p):
For performance, we will need separate unregister calls for heap, stack and
globals.


>> The Address Sanitizer (ASan)
s/Address Sanitizer/AddressSanitizer/ (no spaces) :)

>> convert lscheck checks to fastlscheck
For asan this is useless (though harmless)

>> or remove checks that will always pass at run-time
Yes, please!!! :)


--kcc



On Thu, May 10, 2012 at 2:33 AM, John Criswell <criswell at illinois.edu>wrote:

> On 5/9/12 4:47 PM, John Criswell wrote:
> > Dear Nuno and All,
> >
> > Attached is my first draft of a specification for the run-time checks
> > I would like to propose to replace the use of objectsize for dynamic
> > bounds checking.  It includes a brief description of the checks and
> > examples of how Clang, ASan, and SAFECode could use them.
> >
> > This is a first rough draft.  Questions, comments, criticisms are
> > welcome.  If people are sufficiently interested, I can make revisions
> > based on comments
> >
> > For the curious, implementing the functionality that Nuno wants
> > (described in Section 3.1) would be trivial.  I would need to update
> > two small passes in SAFECode from LLVM 3.0 to LLVM mainline, write a
> > Clang-specific pass that removes calls to gepcheck, and copy the
> > implementation of fastgepcheck into the correct run-time library
> > (compiler-rt?).  With additional work, I could write a new pass that
> > inlines the fastgepcheck so that libLTO isn't needed to inline the
> > fastgepcheck implementation, but that might take a little more time.
>
> Also, just to be clear, I'd be more than happy to do the implementation
> work and submit patches for review if people want to use this approach.
>
> -- John T.
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120510/be512415/attachment.html>