similar to: [LLVMdev] Coverage

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

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

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

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

Hi all, Thought this might be of general interest, I hacked up the pybugz tool to work with llvm.org. It's here if you want it: http://t1.minormatter.com/~ddunbar/pybugz-llvm-0.7.3.tgz Unpack somewhere, and make a link to the 'bugz' script. Usage: -- ddunbar at ozzy-2:~$ bugz get 1000 * Using http://llvm.org/bugs/ * Getting bug 1000 .. Title : Chris Is Buggy Assignee :

Dear All, I am helping our test team migrate from gcov to llvmcov. They currently generate HTML reports using lcov to easily navigate where coverage is missing. However, there does not seem to be a Windows compatible solution for generating HTML reports using the llvm-cov tools. A possible solution to this problem is for llvm-cov to create html pages that include an overall coverage summary

Hello, The following patch series enables LLVM coverage support for the Xen hypervisor. This first patches are a re-organization of the gcov support, in order to make the support generic for all coverage technologies. This is mostly a name change from gcov -> cov in several places and files, together with the addition of a Kconfig option in order to enable LLVM coverage. Patch 7 introduces

Xinliang David Li via llvm-dev <llvm-dev at lists.llvm.org> writes: > Harlan Haskins has recently submitted a patch (for review) that implements > --format=html for llvm-cov tool. Please take a look at that patch. For reference, the review thread starts here: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160229/336622.html > David > > On Thu, Mar 3, 2016 at

Hi All, We trying to use clang+llvm to generate the gcc coverage format as clang version 3.6.0 $clang --coverage -Xclang -coverage-cfg-checksum -Xclang -coverage-no-function-names-in-data -Xclang -coverage-version='407*' test.c $a.out $llvm-cov gcov test.gcda Unexpected version: *704. Invalid .gcno File! Debugging the above cause ,But any hints from experts here ,will help a lot

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

Hi All, I want to provide a solution that presents code coverage reports that include the aggregated code-counts across many binaries. Our test engineers currently do this using gcov-mode by merged .gcda data files. We can do a similar merge of the .profraw files, so that the many binaries are represented in one .profdata file; However, llvm-cov will only generate reports based on one binary at

I’m working to implement Source Based Code Coverage in a workflow that uses lcov for report generation. We’ve customized our llvm-cov to add a command to convert the SBCC counter data to lcov’s ‘.info’ format. The problem is that the region-based counter definitions in SBCC can span source code regions that can contain blank lines (or lines with only comments). Converting this to lcov’s

+ 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

Hi, Alan Thanks for making it clear. But I was more confused now :( I tested on a simple program and used both gcov and lcov to get branch coverage. The code and build commands as below: *Example simple.cc* #include <string> // If not comment this line, the branch coverage won't reach to 100% // #include <iostream> int main(int argc, const char* argv[]) { std::string str =

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

Hi, Alan Really very excited to receive your email and sorry to be slow replying, it has been exceptionally busy over the last few days ;( Your explanation made the problem clear to me. So gcov branch coverage should be called condition coverage and clang region coverage is branch coverage in fact(also known as *decision/C1*), right? And llvm/clang will support all the following coverage

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

Hi all, I was trying to generate lcov test coverage reports for xapian-core but got an out of memory error: $ lcov --capture --directory . --output-file xapian-core.info Capturing coverage data from . Found gcov version: 4.7.3 Scanning . for .gcda files ... Found 270 data files in . Processing bin/xapian-progsrv.gcda Out of memory! These are the steps I followed in xapian-core directory

Hi, viewing the gcov coverage report (accessible via llvm.org -> Coverage in the left bar) yields a 403 access forbidden for most folders. For instance: http://llvm.org/reports/coverage/tools/clang/lib/Parse/index.html Coverage from llvm-cov is still available at http://lab.llvm.org:8080/coverage/coverage-reports/clang/index.html I assume the web server configuration is at fault. Michael

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