[llvm-commits] Specification for Run-time Checks

[John Criswell]

On 5/10/12 1:39 AM, Kostya Serebryany wrote:
> +Ott Tinn
>
> Some comments, mostly related to asan:
>
> >> lscheck (void * ptr, int length)
> length should be size_t

Correct.  I had originally used uintptr_t, but that didn't typeset very 
well.  I decided to be less pedantic to improve readability.
:)

> asan needs to distinguish between reads and writes.

Okay.  We can then have a loadcheck() and a storecheck().

Do you consider the atomic intrinsics (e.g., compare and swap) to be 
stores, or do we need an lscheck() that checks operations that perform a 
load and a store?

>
> >> 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.

First, there are separate instrumentation passes for adding 
pool_register_stack(), pool_register_global(), and 
pool_register_heap().  If a tool does not find one of these functions 
useful, it can simply omit the pass that adds them.

Second, regarding the extra parameters, my plan is to have each tool run 
tool-specific passes to add parameters as needed.  For example, SAFECode 
would add a pool handle argument and, if used as a debugging tool, 
source line and file name arguments.  I assume ASan can have a pass that 
adds the frame description argument.  If that's not possible, please let 
me know.

Third, I am curious to know whether generic optimization of registration 
calls could aid ASan.  Optimizing away a pool_register call basically 
means that all run-time checks on pointers to that memory have either 
been proven safe or are performed using fastlscheck/fastgepcheck.  This 
can speed up SAFECode, but can it also speed up ASan?


> 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

Good point; it would make more sense to have pool_register_global take 
an array of globals and their size.

For the redzones, adding them would be done by an ASan-specific transform.

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

Okay, but just out of curiosity, what performance advantage do you get 
by distinguishing between them?

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

Ah.  Sorry about that.

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

Actually, I'm not sure if that is true.  If I understand correctly, an 
lscheck in ASan will need to perform a load from shadow memory and 
perform a comparison.  A fastlscheck, on the other hand, does two 
comparisons.  If you suffer a cache miss in the shadow memory, I think 
an lscheck could take longer than a fastlscheck.

Also, fastlscheck is easier to optimize.  Since you know the bounds of 
the memory object to which the pointer belongs, you may be able to 
optimize away one or both of the comparisons.

-- John T.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120510/2301533a/attachment.html>