[llvm-commits] Specification for Run-time Checks

[John Criswell]

On 5/10/12 2:17 PM, Kostya Serebryany wrote:
> [snip]
>
>
>>
>>     >> 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?

The pool_register_stack call is used on individual alloca objects.  This 
is because some systems (like SAFECode) want to know the bounds of 
individual stack objects.

What does your instrumentation with the frame description string look 
like?  If I understood that better, I could better tell you whether ASan 
should modify the pool_register_stack calls or whether it should just 
use its own instrumentation pass for that step.

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

Well, the pool_register optimizations won't tell you if a malloc/free 
pair occurs within a function, but it can tell you whether all the 
checks on a memory object avoid using shadow memory.  That might reduce 
overhead by allowing you to skip shadow memory initialization for memory 
objects that don't need it.

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

I see.  That makes sense.


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

Correct.  The transform to convert lscheck to fastlscheck isn't used on 
heap objects at present because the object might have been freed.  The 
optimization can be improved by doing an analysis to see if the object 
can be freed, but that's a future enhancement.

-- John T.

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