[LLVMdev] asan coverage

[Duncan P. N. Exon Smith]

On 2014 Mar 28, at 15:47, Eric Christopher <echristo at gmail.com> wrote:

> On Fri, Mar 28, 2014 at 3:18 PM, Duncan P. N. Exon Smith
> <dexonsmith at apple.com> wrote:
>> 
>> On 2014 Mar 28, at 14:59, Bob Wilson <bob.wilson at apple.com> wrote:
>> 
>>> 
>>> On Mar 28, 2014, at 1:33 AM, Kostya Serebryany <kcc at google.com> wrote:
>>> 
>>>> Some more data on code size.
>>>> 
>>>> I've build CPU2006/483.xalancbmk with
>>>> a) -O2 -fsanitize=address -m64 -gline-tables-only -mllvm -asan-coverage=1
>>>> b) -O2 -fsanitize=address -m64 -gline-tables-only -fprofile-instr-generate
>>>> 
>>>> The first is 27Mb and the second is 48Mb.
>>>> 
>>>> The extra size comes from __llvm_prf_* sections.
>>>> You may be able to make these sections more compact, but you will not make them tiny.
>>>> 
>>>> The instrumentation code generated by -asan-coverage=1 is less efficient than -fprofile-instr-generate
>>>> in several ways (slower, fatter, provides less data).
>>>> But it does not add any extra sections to the binary and wins in the overall binary size.
>>>> Ideally, I'd like to see such options for -fprofile-instr-generate as well.
>>>> 
>>>> --kcc
>>> 
>>> It might make sense to move at least some of the counters into the .bss section so they don't take up space in the executable.
>>> 
>>> We're also seeing that the instrumentation bloats the code size much more than expected and we're still investigating to see why that is the case.
>> 
>> The __llvm_prf_cnts section is likely the largest.  It's zero-initialized,
>> so it's a good candidate for .bss or similar.  The counters are currently in
>> their own section to make write out easy (just one big array), but we could
>> change that.  Or, is there linker magic that can make a special section
>> behave like the .bss?
> 
> Possibly. The zerofill stuff is a bit weird, but you should be able to
> specify a large enough block to zerofill and a concrete section. A
> separate section with the S_ZEROFILL attribute would probably work to
> get it all initialized and just switch sections and not use the
> zerofill directive.
> 
> -eric

Heh, I'm a little lost here.  Where can we specify this?  I had a look
in MCSectionMachO.cpp, and S_ZEROFILL isn't accessible from LLVM IR.
Should we add logic somewhere to recognize these sections?  Will that
actually reduce the executable size?  (I tried hacking it in but that
didn't seem to save disk space.)

Also, this doesn't solve ELF.  Can we do similar things there?

For clarity, there are three __llvm_prf_* sections.  Without having
seen Kostya's data, I'm speculating that __llvm_prf_cnts is the largest
section.

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

In the latter two cases, it's possible to avoid the special sections if
there are good reasons, but it will add runtime overhead.