[LLVMdev] asan coverage

[Kostya Serebryany]

I understand why you don't want to rely on debug info and instead produce
your own section.
We did this with our early version of llvm-based tsan and it was simpler to
implement.
But here is a data point to support my suggestion:
chromium binary built with asan, coverage and -gline-tables-only is 1.6Gb.
The same binary is 1.1Gb when stripped, so, the line tables require 500Mb.
Separate line info for coverage will essentially double this amount.
The size of binary is a serious concern for our users, please take it into
consideration.

Thanks!
--kcc



On Fri, Feb 21, 2014 at 8:28 PM, Bob Wilson <bob.wilson at apple.com> wrote:

> We’re not going to use debug info at all. We’re emitting the counters in
> the clang front-end. We just need to emit separate info to show how to map
> those counters to source locations. Mapping to PCs and then using debug
> info to get from the PCs to the source locations just makes things harder
> and loses information in the process.
>
> On Feb 21, 2014, at 2:57 AM, Kostya Serebryany <kcc at google.com> wrote:
>
>
>>
>> We may need some additional info.
>
> What kind of additional info?
>
>
>> I haven't put a ton of thought into
>> this, but I'm hoping we can either (a) use debug info as is or add some
>> extra (valid) debug info to support this, or (b) add an extra
>> debug-info-like section to instrumented binaries with the information we
>> need.
>>
>
> I'd try this data format (binary equivalent):
>
> /path/to/binary/or/dso1 num_counters1
> pc1 counter1
> pc2 counter2
> pc3 counter3
> ...
> /path/to/binary/or/dso2 num_counters2
> pc1 counter1
> pc2 counter2
> pc3 counter3
> ...
>
> I don't see a straightforward way to produce such data today because
> individual Instructions do not work as labels.
> But I think this can be supported in LLVM codegen.
> Here is a *raw* patch with comments, just to get the idea.
>
>
> Index: lib/CodeGen/CodeGenPGO.cpp
> ===================================================================
> --- lib/CodeGen/CodeGenPGO.cpp  (revision 201843)
> +++ lib/CodeGen/CodeGenPGO.cpp  (working copy)
> @@ -199,7 +199,8 @@
>    llvm::Type *Args[] = {
>      Int8PtrTy,                       // const char *MangledName
>      Int32Ty,                         // uint32_t NumCounters
> -    Int64PtrTy                       // uint64_t *Counters
> +    Int64PtrTy,                       // uint64_t *Counters
> +    Int64PtrTy                       // uint64_t *PCs
>    };
>    llvm::FunctionType *FTy =
>      llvm::FunctionType::get(PGOBuilder.getVoidTy(), Args, false);
> @@ -209,9 +210,10 @@
>    llvm::Constant *MangledName =
>      CGM.GetAddrOfConstantCString(CGM.getMangledName(GD),
> "__llvm_pgo_name");
>    MangledName = llvm::ConstantExpr::getBitCast(MangledName, Int8PtrTy);
> -  PGOBuilder.CreateCall3(EmitFunc, MangledName,
> +  PGOBuilder.CreateCall4(EmitFunc, MangledName,
>                           PGOBuilder.getInt32(NumRegionCounters),
> -                         PGOBuilder.CreateBitCast(RegionCounters,
> Int64PtrTy));
> +                         PGOBuilder.CreateBitCast(RegionCounters,
> Int64PtrTy),
> +                         PGOBuilder.CreateBitCast(RegionPCs, Int64PtrTy));
>  }
>
>  llvm::Function *CodeGenPGO::emitInitialization(CodeGenModule &CGM) {
> @@ -769,6 +771,13 @@
>                               llvm::GlobalVariable::PrivateLinkage,
>                               llvm::Constant::getNullValue(CounterTy),
>                               "__llvm_pgo_ctr");
> +
> +  RegionPCs =
> +    new llvm::GlobalVariable(CGM.getModule(), CounterTy, false,
> +                             llvm::GlobalVariable::PrivateLinkage,
> +                             llvm::Constant::getNullValue(CounterTy),
> +                             "__llvm_pgo_pcs");
> +
>  }
>
>  void CodeGenPGO::emitCounterIncrement(CGBuilderTy &Builder, unsigned
> Counter) {
> @@ -779,6 +788,21 @@
>    llvm::Value *Count = Builder.CreateLoad(Addr, "pgocount");
>    Count = Builder.CreateAdd(Count, Builder.getInt64(1));
>    Builder.CreateStore(Count, Addr);
> +  // We should put the PC of the instruction that increments
> __llvm_pgo_ctr
> +  // into __llvm_pgo_pcs, which will be passed to llvm_pgo_emit.
> +  // This patch is wrong in many ways:
> +  //   * We pass the PC of the Function instead of the PC of the
> Instruction,
> +  //   because the latter doesn't work like this. We'll need to support
> +  //   Instructions as labels in LLVM codegen.
> +  //   * We actually store the PC on each increment, while we should
> initialize
> +  //   this array at link time (need to refactor this code a bit).
> +  //
> +  Builder.CreateStore(
> +      Builder.CreatePointerCast(
> +          cast<llvm::Instruction>(Count)->getParent()->getParent(),
> +          Builder.getInt64Ty()  // FIXME: use a better type
> +          ),
> +      Builder.CreateConstInBoundsGEP2_64(RegionPCs, 0, Counter));
>  }
>
> Index: lib/CodeGen/CodeGenPGO.h
> ===================================================================
> --- lib/CodeGen/CodeGenPGO.h    (revision 201843)
> +++ lib/CodeGen/CodeGenPGO.h    (working copy)
> @@ -59,6 +59,7 @@
>
>    unsigned NumRegionCounters;
>    llvm::GlobalVariable *RegionCounters;
> +  llvm::GlobalVariable *RegionPCs;
>    llvm::DenseMap<const Stmt*, unsigned> *RegionCounterMap;
>    llvm::DenseMap<const Stmt*, uint64_t> *StmtCountMap;
>    std::vector<uint64_t> *RegionCounts;
> @@ -66,8 +67,9 @@
>
>  public:
>    CodeGenPGO(CodeGenModule &CGM)
> -    : CGM(CGM), NumRegionCounters(0), RegionCounters(0),
> RegionCounterMap(0),
> -      StmtCountMap(0), RegionCounts(0), CurrentRegionCount(0) {}
> +      : CGM(CGM), NumRegionCounters(0), RegionCounters(0), RegionPCs(0),
> +        RegionCounterMap(0), StmtCountMap(0), RegionCounts(0),
> +        CurrentRegionCount(0) {}
>    ~CodeGenPGO() {}
>
>    /// Whether or not we have PGO region data for the current function.
> This is
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140222/0a5ed0f2/attachment.html>