similar to: [LLVMdev] LLVM instrumentation

Yeah I have already see pintool but I need this to work with ARM and Intel. If I remember correctly, pintool does not work on ARM (or quite bad). My goal with the instrumentation is, once I have the information (time + call), to choose (during a second compilation) if some of my passes are applicable or not. Greetings, Johan On 17 Jul 2015, at 16:09, Kenneth Adam Miller <kennethadammiller

The PGO was my first guess but I can get a lot of information. At first, I follow the explanation at http://clang.llvm.org/docs/UsersManual.html#profiling-with-instrumentation but instead of llvm-profdata merge, I used llvm-profdata show *.profraw. Sadly, the information I get is the total number of function, the maximum function count and the maximum internal block count. Do you know if you

Hi, I tried to do code coverage testing for libguestfs with gcov. The steps are shown as follows: 1. Download and install the source package(libguestfs-1.36.5-1.el7.src.rpm) 2. Modify libguestfs.spec file #diff -u libguestfs.spec libguestfs.spec.modify --------------------------------------------------------------------------------------- --- libguestfs.spec 2017-08-29 02:44:35.623751541 -0400

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

HI Mats, > On 22 Feb 2016, at 16:48, mats petersson <mats at planetcatfish.com> wrote: > > And you want this for only SOME bits of code, and that's why you need to have the IR report what sections are "sensitive"? Exactly and I want to chose this once the compilation is over. > It would be fairly easy if the code you want to check is a normal functions, just

Hi everyone, I’m currently playing with the clang driver and I encounter a strange bug. It occurs when I used the getSize function from the SymbolRef class. On iOS, the number returned is not always correct (some function have the right size). Sadly, This is my code (at the end of the main function into driver.cpp) : #### ErrorOr<OwningBinary<Binary>> BinaryOrErr =

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

Ah, my mistake. So this already works. I guess that bug is out of date, since this feature works already. -- John Harrison On Wed, Feb 6, 2013 at 10:00 AM, Joshua Cranmer <pidgeot18 at gmail.com> wrote: > On 2/6/2013 11:43 AM, John Harrison wrote: > >> The way `-ftest-coverage -fprofile-arcs` works at the moment it only >> flushes via `atexit()`. This patch allows you

Hi everyone, I encountered a strange bug when I tried to compile openssl (https://www.openssl.org/) with clang and llvm-ar on a 64-bit OS X. I changed the openssl makefile to use llvm-ar instead of simply ar. Openssl will then create two static libraries libssl.a and libcrypto.a. The problem occurs when it tries to link these two static libraries to the final openssl executable. I get the

The way `-ftest-coverage -fprofile-arcs` works at the moment it only flushes via `atexit()`. This patch allows you to flush the coverage at any point by calling `__llvm_gcov_flush` the same way `__gcov_flush` works for gcc. If there is another way of doing this, I might of missed it but I was looking for `__gcov_flush` and I did not find the equivalent in llvm at the moment. -- John Harrison

I will try to explain better what I do. The main goal behind this is to verify that a part of code is not modified by someone else (it is an integrity check). To do this, I create in IR a function who take 2 parameters, a begin and an end value. This function perform an hash over the code area (from begin to end) and return it. At first, I don’t know the addresses and the hash value so I put

----- Original Message ----- > On Thu, Aug 31, 2017 at 05:45:38AM -0400, Yongkui Guo wrote: > > Hi, > > > > I tried to do code coverage testing for libguestfs with gcov. > > > > The steps are shown as follows: > > 1. Download and install the source package(libguestfs-1.36.5-1.el7.src.rpm) > > Probably best to try building this from git instead of

Why does __gcov_flush only flush the current compilation unit? For gcc __gcov_flush flushes all of the loaded files. Is there a way to have __gcov_flush flush everything? -- John Harrison On Wed, Feb 6, 2013 at 10:24 AM, John Harrison <ash.gti at gmail.com> wrote: > Ah, my mistake. So this already works. I guess that bug is out of date, > since this feature works already. >

Hello guys, Today I tried to find the amount of LLD(elf) code covered by our test cases. So my aim was to run the LLD tests we have (run check-lld task) and find out which code was executed/covered and which was not. I used the approach from the next article to do that: http://logan.tw/posts/2015/04/28/check-code-coverage-with-clang-and-lcov/#create-a-wrapper-script-for-lcov In short, it is

Hi Everyone, I have uploaded a patch that allows one to successfully gather gcov/gcda coverage information on programs which unload shared libraries. It¹s a simple fix, just adding a few COMPILER_RT_VISIBILITY (i.e. __attribute__((visibility("hidden")))) in GCDAProfiling.c. Now, I¹d like to include a test program to demonstrate the fix. AFAICT, there seems to be a single test for

On 2/6/2013 11:43 AM, John Harrison wrote: > The way `-ftest-coverage -fprofile-arcs` works at the moment it only > flushes via `atexit()`. This patch allows you to flush the coverage at > any point by calling `__llvm_gcov_flush` the same way `__gcov_flush` > works for gcc. > > If there is another way of doing this, I might of missed it but I was > looking for

Yikes! It only flushes the counts for the current compilation unit? That sounds like a terrible bug. Can you file a bugzilla report, please? On Feb 6, 2013, at 12:05 PM, John Harrison <ash.gti at gmail.com> wrote: > Why does __gcov_flush only flush the current compilation unit? For gcc __gcov_flush flushes all of the loaded files. > > Is there a way to have __gcov_flush flush

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

Thanks a lot for doing this. Having it automated an in a bot would be really nice. Cheers, Rafael George Rimar <grimar at accesssoftek.com> writes: > Hello guys, > > Today I tried to find the amount of LLD(elf) code covered by our test cases. So my aim was to run the LLD tests we have (run check-lld task) and find out which code was executed/covered and which was not. > >