[llvm-commits] Specification for Run-time Checks

[Kostya Serebryany]

>
> Okay.  We can then have a loadcheck() and a storecheck().
>
> Do you consider the atomic intrinsics (e.g., compare and swap) to be
> stores,
>

It's fine to treat those as 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.
>

Ok. What I still don't understand: do you plan to call pool_register_stack
for every alloca or for the whole frame?



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

Yes, such optimizations are possible.
E.g. if we have a malloc/free pair and the pointer does not escape he
current function, a lot of simplifications can be done.


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

And then again asan needs to pass more than the addresseses and sizes. Not
a big deal, of course.



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

Some of them will need to be inlined. If you don't distinguish the types it
may be harder.


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

yea, good point. A couple of arithmetic instructions is usually better than
a load.
This will have to fire only when the pointer is known to be alive (not
dangling).

--kcc


> 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/dd37aa6b/attachment.html>