similar to: Introducing the binary-level coverage analysis tool bcov

Hi Fangrui, Many thanks for providing such detailed feedback! Please find my comments inlined below. - Ammar On Sun, Jun 28, 2020 at 5:59 AM Fangrui Song <maskray at google.com> wrote: > On 2020-06-26, Ammar Ben Khadra via llvm-dev wrote: > >## TL;DR > > > >We introduce bcov, an open-source binary-level coverage analysis tool [1]. > >The details are discussed

+ Vedant Hi Hal, thanks. I apologize if my answers aren't as thorough as you would like; what I'm proposing is simply an extension to the existing infrastructure, so it would be enabled automatically as part of code coverage. Mapping of branch regions would be done in CoverageMappingGen and instrumented using the same profiling instrumentation mechanism under

On Feb 12, 2014, at 10:31 AM, Kostya Serebryany <kcc at google.com> wrote: > Hi, > > Justin is making nice commits for llvm-cov, so I thought we may continue this discussion now. > The quick-and-dirty implementation of coverage (in asan) is getting some early users and they seem to be happy. > AsanCoverage allows to collect per-function or per-basic-block coverage

Vedant Kumar asked me to post my design thoughts concerning branch coverage at llvm-dev since there is general interest. My team at Texas Instruments is developing an embedded ARM C/C++ compiler with LLVM. I would like to enhance LLVM's code coverage capability with branch condition coverage (for C/C++), similar to GCC/GCOV support for branch coverage. This is useful for TI, and I think

On Feb 12, 2014, at 11:43 PM, Kostya Serebryany <kcc at google.com> wrote: > > > > On Thu, Feb 13, 2014 at 11:10 AM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Feb 12, 2014, at 10:31 AM, Kostya Serebryany <kcc at google.com> wrote: > >> Hi, >> >> Justin is making nice commits for llvm-cov, so I thought we may continue this

> On Aug 24, 2017, at 2:55 PM, Kostya Serebryany <kcc at google.com> wrote: > > Interesting. > This is a relatively new addition (fsanitize-coverage=pc-tables, which is now a part of -fsanitize=fuzzer). > The tests worked (did they? On Mac?) so I thought everything is ok. For tests we never compile the tested target with -O3 (and that wouldn’t be sufficient), and for

Given the following C++ code: ``` // test.cpp struct Foo { int public_foo(); int outside_foo(); [[gnu::always_inline]] int inline_foo() { int x = outside_foo(); if (x % 17) { x += 1; } return x; } [[gnu::noinline]] int inline_bar1() { int x = inline_foo(); if (x % 23) { x += 2; } return x; } [[gnu::noinline]] int inline_bar2() {

On Thu, Aug 24, 2017 at 3:21 PM, Kostya Serebryany via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Aug 24, 2017 at 3:20 PM, Justin Bogner <mail at justinbogner.com> > wrote: > >> I think the simplest fix is something like this: >> >> diff --git a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp >>

I think the simplest fix is something like this: diff --git a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp b/lib/Transforms/Instrumentation/SanitizerCoverage.cpp index c6f0d17f8fe..e81957ab80a 100644 --- a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp +++ b/lib/Transforms/Instrumentation/SanitizerCoverage.cpp @@ -256,6 +256,7 @@ SanitizerCoverageModule::CreateSecStartEnd(Module

Hi Justin , Thank you for the confirmation and we would like to know that ,going forward the clang has the support the gcc gcov format or use the -fprofile-instr-generate -fcoverage-mapping and get ride of gcov format . We are planing to customize the clang code coverage for embedded world ,before we start tweaking the gcov / -fprofile-instr-generate code-base ,we would like to take feedback

Hello, Our goals for the code coverage BoF (10/19) were to find areas where we can improve the coverage tooling, and to learn more about how coverage is used. I'd like to thank all of the attendees for their input and for making the BoF productive. Special thanks to Mandeep Grang, who volunteered as a mic runner at the last minute. In this email I'll share my (rough) notes and outline

On Thu, Aug 24, 2017 at 3:38 PM, Kostya Serebryany <kcc at google.com> wrote: > > > On Thu, Aug 24, 2017 at 3:35 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> On Thu, Aug 24, 2017 at 3:21 PM, Kostya Serebryany via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> >>> >>> On Thu, Aug 24, 2017 at 3:20

On Thu, Aug 24, 2017 at 6:30 PM, Justin Bogner <mail at justinbogner.com> wrote: > Peter Collingbourne <peter at pcc.me.uk> writes: > > On Thu, Aug 24, 2017 at 3:38 PM, Kostya Serebryany <kcc at google.com> > wrote: > > > >> > >> > >> On Thu, Aug 24, 2017 at 3:35 PM, Peter Collingbourne <peter at pcc.me.uk> > >> wrote:

Updated set of patches for coverage. Changes: - change copyright lines - use gcov: instead of cover: in commit comment - use #ifdef in xen/common/sysctl.c instead of dummy inline function - added base documentation in docs/misc - added -h option to xencov

Umesh Kalappa <umesh.kalappa0 at gmail.com> writes: > Hi Justin , > > Thank you for the confirmation and we would like to know that ,going > forward the clang has the support the gcc gcov format or use the > -fprofile-instr-generate -fcoverage-mapping and get ride of gcov > format . Going forward, the -fprofile-instr-generate -fcoverage-mapping (which I'll refer to as

Kostya Serebryany <kcc at google.com> writes: > Justin, > Calling appendToUsed has horrible complexity and if we call it in > every function clang consumes tons of memory (6Gb when compiling one > of the clang's source files). This killed my machine today :) > > The solution is to call appendToUsed once per module, instead of once > per function. Oh right,

Bob, Justin, I've just committed a poor man's coverage implementation that works with asan. http://llvm.org/viewvc/llvm-project?rev=194701&view=rev http://llvm.org/viewvc/llvm-project?rev=194702&view=rev It provides only function-level boolean coverage (i.e. no counters, just "visited or not"), but is very fast and very simple (no extra sections to the binary file, etc)

Hi Dean, We didn't discuss using XRay instrumentation during the BoF but it is an interesting idea (by the way, thanks for your talk about XRay internals!). XRay provides the advantage of being able to turn profiling on and off, but I'm not sure how the resulting data could be used. The code coverage feature is highly dependent on the frontend's profile counter placement. The mapping

Hi, llvm/clang experts I need to get the branch coverage for some testing code. But i found gcov can't give a expected coverage which may count some 'hidden branch' in (See stackoverflow answer <https://stackoverflow.com/questions/42003783/lcov-gcov-branch-coverage-with-c-producing-branches-all-over-the-place>). Instead, I turn to use clang and the 'source-based code

Hello, I have few questions about coverage. Is there any user-facing documentation for clang's "-coverage" flag? The coverage instrumentation seems to happen before asan, and so if asan is also enabled asan will instrument accesses to @__llvm_gcov_ctr. This is undesirable and so we'd like to skip these accesses. Looks like GEP around @__llvm_gcov_ctr have special metadata