[LLVMdev] asan coverage

[Bob Wilson]

On Mar 31, 2014, at 1:53 AM, Kostya Serebryany <kcc at google.com> wrote:
> 
> This is what I see on 483.xalancbmk:
>  15 __llvm_prf_names 0036fcb0  00000000010abf40  00000000010abf40  00cabf40  2**5
>  16 __llvm_prf_data 001b77e0  000000000141bc00  000000000141bc00  0101bc00  2**5
>  32 __llvm_prf_cnts 00123468  0000000001af2fe0  0000000001af2fe0  014f2fe0  2**5
> 
> __llvm_prf_names is larger than the other two combined. 
> 483.xalancbmk is C++ and the function names are long. The same is true for most of the code we care about.
> Can't we use function PCs instead of function names in this table (and retrieve the function names from debug info)?

That’s a bit surprising. We should check to make sure there isn’t anything obviously wrong.

> 
>  
> 
>   - __llvm_prf_data is 32B per function, and has pointers into the
>     other two sections.  This section is necessary to avoid static
>     initialization (implemented on Darwin, not quite on ELF).
> 
>   - __llvm_prf_names is the mangled name of every function.  It should
>     be on the same order of magnitude as __llvm_prf_data.  This
>     section is convenient for writing out the profile, since the names
>     are effectively placed in one big char array whose bounds are known
>     at link time.
> 
>   - __llvm_prf_cnts is 8B per region counter.  Each function has one
>     at entry and roughly one per CFG-relevant AST node (for, if, etc.).
>     This section is convenient for writing out the profile, since the
>     counters are effectively placed in one big array whose bounds are
>     known at link time.  However, I don't think the data in this
>     section needs to be explicitly stored in the executable if we can
>     somehow make it act like .bss (or the like).
> 
> Why can't we simply create this buffer at startup? 
> We solve similar task in asan, so it's definitely possible. 

We need this to work for environments where minimal runtime support is available (e.g., in kernel code). We used to call malloc() to create some data structures at runtime but that prevented us from using it from kernel code. I’m hoping the additional size will not be such a problem that we have to implement separate solutions for different environments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140331/85927eab/attachment.html>