search for: covmap

Hi David, Vedant, It looks like we might have UB somewhere connected with reading coverage mapping serialized in v2 format (with compressed function names). I committed my patch, r266436, using the current format for .covmapping file, and then buildbots complained about it: * http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/11935/steps/check-llvm%20ubsan/logs/stdio * http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/11460/steps/check-llvm%20ubsan/logs/stdio I tried to rep...

...al function names but > instead MD5 hashes, Yes. To support your use case, there are two solutions: 1) user can add -fcoverage-mapping option in the build 2) introduce a new option -fprofile-instr-names that force the emission of the name sections in the .o file. This is similar to 1), but no covmap section is needed. llvm-profdata tool will be taught to read the name section and attach function names to the profile records. Note that with 1) or 2), the user can still benefit from the reduced profile size. thanks, David >which will make it more difficult for me to do this kind >...

...roved. Instead of using static symbol table (with zero size __llvm_prf_nm symbols) to store function names for profile display and coverage mapping, the function names can be stored compressed in a non-allocatable section. The compression ratio for function name strings can be very high (~5x). The covmapping data can also be made non-allocatable. thanks, David On Tue, Sep 29, 2015 at 9:52 AM, Xinliang David Li <davidxl at google.com> wrote: > Sorry for the late update. I finally found time to implement a solution > (Solution-3) that has the best size savings (for both PGO and coverag...

...l >> table (with zero size __llvm_prf_nm symbols) to store function names >> for profile display and coverage mapping, the function names can be >> stored compressed in a non-allocatable section. The compression ratio >> for function name strings can be very high (~5x). The covmapping data >> can also be made non-allocatable. >> >> thanks, >> >> David >> >> On Tue, Sep 29, 2015 at 9:52 AM, Xinliang David Li <davidxl at google.com> >> wrote: >> > Sorry for the late update. I finally found time to implement a solut...

...ero size __llvm_prf_nm symbols) to store function names >>>> for profile display and coverage mapping, the function names can be >>>> stored compressed in a non-allocatable section. The compression ratio >>>> for function name strings can be very high (~5x). The covmapping data >>>> can also be made non-allocatable. >>>> >>>> thanks, >>>> >>>> David >>>> >>>> On Tue, Sep 29, 2015 at 9:52 AM, Xinliang David Li <davidxl at google.com> >>>> wrote: >>>> &...

...xisting design does have its own advantage -- making it easier for tool to access 'debug' info for counters. LLVM's coverage testing, on the other hand, take a hybrid approach: It emits the coverage map as rodata, but does not pass it to the profile dumper. I think it is better to emit covmap as a side data not attached to target binary. > > Thus, as we require that the binary be passed to llvm-profdata, there is no > fundamental reason that the memory image of the program, or the raw data > extracted from the program, must have any size overhead besides the raw > value...

...>> To support your use case, there are two solutions: >> >> 1) user can add -fcoverage-mapping option in the build >> 2) introduce a new option -fprofile-instr-names that force the >> emission of the name sections in the .o file. This is similar to 1), >> but no covmap section is needed. >> >> llvm-profdata tool will be taught to read the name section and attach >> function names to the profile records. > > > Needing to pass the executable to llvm-profdata would cause deployment > issues for my customers in practice. Why? The deplo...

...coverage-mapping is specified, the llvm_prf_names will be emitted to the binary, but they won't be dumped into the profile data. In other words, with -fcoverage-mapping, only profile data will be shrinked. The reason is that llvm-cov tool reads function names from the section (referenced from covmap) to support name based filtering (including regular expression) when dumping line coverage report 2) The change is backward compatible such that old version of both raw and index formats can still be read by the new profile reader (and therefore clients such as clang, llvm-profdata, llvm-cov tools...

...two solutions: >> >> >> >> 1) user can add -fcoverage-mapping option in the build >> >> 2) introduce a new option -fprofile-instr-names that force the >> >> emission of the name sections in the .o file. This is similar to 1), >> >> but no covmap section is needed. >> >> >> >> llvm-profdata tool will be taught to read the name section and attach >> >> function names to the profile records. >> > >> > >> > Needing to pass the executable to llvm-profdata would cause deployment &gt...

...t;> >> >> 1) user can add -fcoverage-mapping option in the build >> >> >> 2) introduce a new option -fprofile-instr-names that force the >> >> >> emission of the name sections in the .o file. This is similar to 1), >> >> >> but no covmap section is needed. >> >> >> >> >> >> llvm-profdata tool will be taught to read the name section and >> >> >> attach >> >> >> function names to the profile records. >> >> > >> >> > >> >&gt...