[LLVMdev] asan coverage

[Kostya Serebryany]

On Sat, Mar 29, 2014 at 4:02 AM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:

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

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



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

--kcc


>
> In the latter two cases, it's possible to avoid the special sections if
> there are good reasons, but it will add runtime overhead.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140331/9b312d89/attachment.html>