gcov

What are your tips for interpreting gcov output in order to improve coverage?

回眸只為那壹抹淺笑 提交于 2019-12-04 07:06:46
I'm successfully using gcov in my project: I can build my project with gcov flags: -fprofile-arcs -ftest-coverage I link with the -lgcov option I run my unit test program and lots of gcda and gcno files are produced. I run gcov lots of times and lots of gcov files are produced. I summarise the results and produce a list of lines like this: #####: 42: virtual double run_time() const { return 0; } I then go 'doh!' and write a test which calls that missing method. The above example line is quite easy to diagnose - gcov told me the exact method I was not calling. I've also had an example of a copy

How do the code coverage options of GCC work?

自古美人都是妖i 提交于 2019-12-04 06:22:20
Consider the following command: gcc -fprofile-arcs -ftest-coverage main.c It generates the file, main.gcda, which is to be used by gcov, to generate the coverage analysis. So how does main.gcda is generated? How the instrumentation is done? Can I see the instrumented code? .gcda is not generated by compiler; it's generated by your program when you execute it. .gcno is the file generated at compilation time and it is the 'note file'. gcc generate a basic block graph notes file (.gcno) for each CU(compiler unit). So how does main.gcda is generated? At running time the statistic data is gathered

C++ using GCOV/LCOV in a CMake project

我只是一个虾纸丫 提交于 2019-12-04 05:50:36
I'm working in a C++ Project with a structure similiar to the following: --- /src |--comms |--utils |--interfaces … CMakeList.txt --- /test |---test1/ |--main.cpp |--CMakelists.txt --CMakeLists.txt I do need to control the coverage of my tests and for this purpose I use GCOV and LCOV in this way: Enable coverage flags in all CMakeLists.txt to let the generation of .gcno files. SET(CMAKE_CXX_FLAGS "-g -O0 -Wall -fprofile-arcs -ftest-coverage") SET(CMAKE_C_FLAGS "-g -O0 -Wall -W -fprofile-arcs -ftest-coverage") SET(CMAKE_EXE_LINKER_FLAGS "-fprofile-arcs -ftest-coverage") Run test, generating the

Linking LLVM causes gcov to fail

十年热恋 提交于 2019-12-04 04:00:52
问题 Passing --coverage to gcc while also linking LLVM causes an undefined reference to `__gcov_exit' error from the linker. I've set up a fresh project to try to isolate this problem. You can view the source on github and inspect the compiler output on Travis-CI. This is the difference between a coverage and a non-coverage build -DCMAKE_CXX_FLAGS="--coverage" This is the difference between an LLVM and a non-LLVM build target_link_libraries(Test PUBLIC LLVMCore ) The LLVM job succeeds. The

can gcov deal with shared object?

若如初见. 提交于 2019-12-03 21:47:12
问题 I am recently using gcov to collect the code coverage info. gcov plays well with executable application :) , but when I try to load a .so file, I got this error: unknown symbol __gcov_merge_add. Then I search on Google and someone said adding -lgcov to the link flag(LDFLAGS), I did add this option and it didn't work. I also try on --coverage option in link flag, cannot get rid of this error. Can someone help on this issue? Thank you. 回答1: I ran into that problem too, but have since solved it.

Is it possible code coverage of a shared library using gcov?

跟風遠走 提交于 2019-12-03 21:09:47
I try to test an executable which uses OpenCV shared library. When using gcov to know what code lines were covered I only get info about my .cpp files and .hpp of the library. No info is shown about .cpp files of the library. I compiled and linked with -pg --coverage flags. Yes, gcov can give coverage information about a shared library. If I remember correctly from the problems I had getting this to work on my project, you're probably not including the --coverage flag on the linking of the dynamic library. Here's the smallest example I could create. Makefile: CXXFLAGS += --coverage LDFLAGS +=

Crossprofiling with gcov, but GCOV_PREFIX and GCOV_PREFIX_STRIP is ignored

牧云@^-^@ 提交于 2019-12-03 17:20:40
问题 I want to use GCOV to make code coverage but the tests will run on another machine. So the hard wired path to .gcda files in the executable won't work. In order to change this default directory I can use the GCOV_PREFIX and GCOV_PREFIX_STRIP env vars, as it's said here. Here my commands I used: $ export GCOV_PREFIX="/foo/bar" $ export GCOV_PREFIX_STRIP="3" $ gcc main.c -fprofile-arcs -ftest-coverage $ strings a.out | grep gcda /home/calmarius/blahblah/main.c.gcda The path remains the same.

gcov out of memory / mismatched version?

╄→尐↘猪︶ㄣ 提交于 2019-12-03 15:14:03
问题 Just trying to get gcov up and running, getting the following error: $ gcov src/main.c -o build build/main.gcno:version '404*', prefer '407*' gcov: out of memory allocating 14819216480 bytes after a total of 135168 bytes I'm using clang/profile_rt to generate the files gcov needs, I'm assuming that might have something to do with it. It's working on my other computer, though, so I assume it can be fixed somehow. 回答1: I just had the same problem on my machine. Make sure your versions of gcov

Understanding branches in gcov files

喜夏-厌秋 提交于 2019-12-03 14:37:36
I'm trying to understand the output of the gcov tool. Running it with no options makes sense, but I'm wanting to try and understand the branch coverage options. Unfortunately it's hard to make sense of what the branches do and why they aren't taken. Below is the output for a method (compile using the latest LLVM/Clang build). function -[TestCoverageAppDelegate loopThroughArray:] called 5 returned 100% blocks executed 88% 5: 30:- (NSInteger)loopThroughArray:(NSArray *)array { 5: 31: NSInteger i = 0; 22: 32: for (NSString *string in array) { branch 0 taken 0 branch 1 taken 7 -: 33: 22: 34: }

How to do code coverage on embedded

∥☆過路亽.° 提交于 2019-12-03 14:02:19
问题 I write a project for a non POSIX embedded system so I cannot use gcc option --coverage (i don't have read or write). What else can I do to produce gcov like output. I do have an output function. 回答1: It can be most easily done with by a processor with embedded trace, a board design that exposes the trace port, and a suitable hardware debugger and associate software. For example, many Cortex-M based devices include ARM's embedded trace macrocell (ETM), and this is supported by Keil's uVision