I've created simple hello word cpp app.
Compiled it by passing gcc --coverage flag
Executed the executable
Generated coverage by invoking
lcov --directory . --capture --output-file ic.info
Generated html based report by genhtml
genhtml -o html/ ic.info
Now the question. No matter how many times I'm running the executable I'm getting always the same result, i.e. the same coverage of lines and functions. Should it increase the line coverage for every execution ? Do I get something wrong ?
If lcov generates coverage only for one execution, then how can I generate coverage for all executions that I've done ?
I guess you misunderstand how the coverage results are generated. lcov is not generating the coverage, as stated in your question. It only processes the coverage results, which are generated when running your program (step 3 in your question).
So, when executing the program multiple times (step 3) your line execution times will increase (not necessary the coverage). To see this you can generated multiple coverage reports (execute step 3,4 and 5 multiple times). You will see an increase in the execution times of lines in your code in the reports generated in step 5.
Related
If I create a new C11 application in Netbeans (with auto-generated makefile), add a dummy function to its main.c file that just returns 0, add a test to the function, and run the test via Netbeans from the test folder, I get the following error:
make: *** [nbproject/Makefile-impl.mk:73: .test-impl] Broken pipe
However, when I debug the test, it works properly. I get varying results when testing the whole project-- sometimes the output ends with the following message:
CUnit - A unit testing framework for C - Version 2.1-3
http://cunit.sourceforge.net/
And sometimes I get the same error. Regardless the actual test results don't get output. Although if I close Netbeans and reopen, the first time I try to test the project the results are displayed correctly, although not any of the subsequent tries.
Any idea what this could be?
This is using CUnit 2.1.3-1, make 4.2.1-2, and gdb 7.12.1-2, all in cygwin 2.10.0 running on Windows 10.
Here's lines 71-73 of the makefile it's referring to, if that helps:
.test-impl: .build-tests-impl .test-pre
##echo "=> Running $#... Configuration=$(CONF)"
"${MAKE}" -f nbproject/Makefile-${CONF}.mk SUBPROJECTS=${SUBPROJECTS} .test-conf
Of course I can provide more of that file if needed, although you should get the same one if you reproduce the steps that led me to the error.
When I run gcov then the output says 87% covered... then I want to use gcovr, but it does never work. I tried to run from many directories, with lots of options. In some cases, a few files I get coverage but not the file I want to see.
My project consists of 3 files:
src\main.c
src\makefile
tst\test1.c
tst\test2.c
tst\makefile
tst\obj\all object files, gcno, gcda are stored here...
build\build.bat to make the project (windows)
Should I change the directory structure? How to see which version of gcov I should use?
I want to see the coverage for main.c, but only get the coverage for test1.c and test2.c and those are not relevant for coverage!!
Next to the test files, I have include directories on C:\compiler which are not required for coverage.
I tried Python27:
python c:\python27\scripts\gcovr -g --object-directory=. -r ..\..\..\ --html --html-details -o program.html -v
I tried Python36:
c:\python36\scripts\gcovr --use-gcov-files -v --object-dir=.
But never get the coverage for my device under test. Only gcov without gcovr works, so the files must be correct.
try add -f '' option. There bug in gcovr which is getting out when we build out of tree
I found several problems when running the GCOVR in Windows, especially concerning \ instead of / and using colon character : in the name like C:\file.c
When you use \ it needs to use 2 of them \ and somewhere in the gcovr it changes to \\ or \\\ ... this is not going well, at some point it tries to find the root of your source files by subtracting 2 paths. but it cannot find this, e.g.
\a\b\c\d it will not find in \a\b\c\d . So, look in : [github.com/barthoukes/gcovr][1]
THe solution is still very dirty, but it works for my projects in Windows. I think the gcovr people also are discussing this problem.
You only need the file: gcovr
I using Coverity to analyze code C.
config command:
cov-configure --compiler /opt/toolchains/stbgcc-4.5.4-2.9/bin/mipsel-linux-uclibc-gcc --comptype gcc --config /opt/cov-analysis-linux64-7.5.1/config/coverity_config.xml
And configuration step is successfully.
Build command:
cov-build --dir ../platform/drivers --record-only --encoding EUC-KR sudo make platform FORCE=1
When coverity build had finished,
i saw in build-log: The cov-build utility completed successfully.
And the warning in pop up block:
the build capture percentage is undesirably 0%
Then i still analyze data:
Analyze command:
cov-analyze --user-model-file >~/work/CoverityData/stdioUserModel.xmldb --parse-warnings-config >~/work/CoverityData/parse_warnings.conf --dir ../platform/drivers/ >--all --checker-option NO_EFFECT:extra_comma:0 -j 4
and i got error:
Error: intermediate directory contains no translation units.
I guess the warning in build-step made the error in analysis step.
Please help me solve this.
The issue may be with the --record-only portion of your cov-build invocation - that captures the compiler invocations, but doesn't actually emit them. Try removing that and try again. Alternatively, you could use cov-build --replay -j X to replay those compilations; some caveats apply, it's usually best to capture the compilations directly.
Please note that using sudo in your build command is exceptionally dangerous and should be avoided. Is it really necessary?
You should check in the build_log file, located in ../platform/drivers/.
Look for lines containing [ERROR] - there may be errors locating header files etc.
Another possibility is to perform a test build first - this might only be possible from the IDE - to ensure that the build is being invoked correctly
Could Someone kindly tell me how can I profile single lines or blocks of code of a program in C with GNU profiler?
I used gprof ./a.out gmon.out which gives me flat profile and Call graph. However, I would like to see lines that are more frequently accessed.
Thanks,
This is probably one of those things that you just don't know the term you should've googled, so I'll answer it:
The term you are looking for is "annotation"-you want to annotate the source and see the line by line hits in the code.
Calling gprof with the -A flag will dump out the samples on each line that were caught.
See Also:
https://sourceware.org/binutils/docs/gprof/Annotated-Source.html
Ok, I'll post this answer so if some newbie like me searched for it can find it faster :)
here are the steps: source
gcc -fprofile-arcs -ftest-coverage fourcefile.c
(At the end of compilation files *.gcno will be produced)
Run the executable.
Run gcov: gcov sourcefile.c
(At the end of running, a file (*.gcov) will be produced which contains which contains all the required info)
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 and stored in memory. Some exit callback is registered and is called to write the data to the .gcda file when the program terminates. This means if you call abort() instead of exit() in your program, no .gcda file would be generated.
How the instrumentation is done? Can I see the instrumented code?
You way need check gcc's implementation to get the details but basically the instrumentation is done by inserting instruction to the program to count the number of times each instruction is executed. But it doesn't really have to keep a counter for each instruction; GCC uses some algorithm to generate a program flow graph and finds a spanning tree for the graph. Only some special arcs have to be instrumented and from them the coverage of all code branches can be generated.
You can disassemble the binary to see the instrumented code.
And here are some files for coverage if you want to look into the gcc source file:
toplev.c
coverage.c
profile.c
libgcov.c
gcov.c
gcov-io.c
edit: some known gcov bugs FYI:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49484
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28441
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44779
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7970
Can I see the instrumented code?
You cannot see the instrumented data like gcda files .
How Gcov works ?
GCOV works in four phases:
1. Code instrumentation during compilation
2. Data collection during code execution
3. Data extraction at program exit time
4. Coverage analysis and presentation post-mortem.
to know more about individual steps u can go through this pdf.
http://ltp.sourceforge.net/documentation/technical_papers/gcov-ols2003.pdf
You can see which code related to gcov is instrumented at compile time executable or obj file, you can use following steps.
nm executable/objfile
Below is image attached of steps and output : -