[llvm-commits] Specification for Run-time Checks

[Nuno Lopes]

Hi John et al.,

I read your proposal and all emails in the discussion.
I must say that, for now, this proposal goes a bit too far for our purposes.
Our idea is to have both quick checks and a fast implementation on the  
compiler side. Your proposal introduces quite a lot overhead a priori.
We would prefer a more lazy approach. I think you/we could apply your  
strategy after we lower most of the objectsize calls. The remaining  
ones will be the ones that we don't know how to implement efficiently,  
and therefore they need more heavyweight techniques like the ones  
you're proposing.
That way you can focus only on the difficult cases, letting the  
compiler discharge the trivial ones for you.  We'll be implementing  
optimizations for objectsize as well.

I'm certainly not the best person to provide any more specific  
feedback on this proposal. I think you already got some nice feedback  
from ASan's crew.  I should have more ideas in a few weeks, after  
fiddling around with this.

Nuno


Citando John Criswell <criswell at illinois.edu>:

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