How to - gcov/lcov for linux user space process

To test & explore gcov/lcov functionality for user space applications, here are the steps I used:

• I wanted to get coverage for a few android tools that I ported to linux a while ago. Here is the code: https://github.com/babuneelam/gcov_uspace_tests. Here is the structure of my applications' source code:

root@babu-VirtualBox:~/gcov_tests# ls -LR

.:

bin  latencytop  Makefile  sane_schedstat  showmap

./bin:

./latencytop:

DumpGcovData  latencytop.c  Makefile

./sane_schedstat:

Makefile  sane_schedstat.c

./showmap:

Makefile  showmap.c

root@babu-VirtualBox:~/gcov_tests# 

• To instrument the code with gcov, I enabled gcov compilation flags in two applications latencytop & sane_schedstat. I also turned off any gcc optimization by removing "O" flags :

root@babu-VirtualBox:~/gcov_tests# grep -irne "-fprofile-arcs" *

latencytop/Makefile:6:CFLAGS       = -fPIC -pedantic -fprofile-arcs -ftest-coverage -march=native -ggdb3

sane_schedstat/Makefile:6:CFLAGS       = -fPIC -pedantic -fprofile-arcs -ftest-coverage -march=native -ggdb3

root@babu-VirtualBox:~/gcov_tests# 

• I compiled all the applications from top directory:

root@babu-VirtualBox:~/gcov_tests# make

• After compilation, I see that gcc generated .gcov files in the two applications instrumented with gcov flags:

root@babu-VirtualBox:~/gcov_tests# ls -LR

.:

bin  latencytop  Makefile  sane_schedstat  showmap

./bin:

latencytop  sane_schedstat  showmap

./latencytop:

latencytop.c  latencytop.gcno  latencytop.o  Makefile

./sane_schedstat:

Makefile  sane_schedstat.c  sane_schedstat.gcno  sane_schedstat.o

./showmap:

Makefile  showmap.c  showmap.o

root@babu-VirtualBox:~/gcov_tests# 

• I then executed latencytop & sane_schedstat binaries in two different terminals. Both these applications run in a loop. So, these commands kept looping in those terminals.

          
               

• I then dumped gcov run time date using a custom script I wrote - https://github.com/babuneelam/gcov_scripts/blob/master/dump_gcov. This script basically attaches to the process through gdb & flushes gcov run time data & then detaches from gdb.

root@babu-VirtualBox:~/gcov_tests# ./dump_gcov latencytop  sane_schedstat

Application: latencytop 
Dumping gcov data...
Gcov data dump complete.

Application: sane_schedstat 
Dumping gcov data...
Gcov data dump complete.
  
root@babu-VirtualBox:~/gcov_tests# 

• After this, I see that dump_gcov script generated .gcda files in the two applications instrumented with gcov flags.

root@babu-VirtualBox:~/gcov_tests# ls -LR

.:

bin  dump_gcov  latencytop  Makefile  sane_schedstat  showmap

./bin:

latencytop  sane_schedstat  showmap

./latencytop:

DumpGcovData  latencytop.gcda  latencytop.o

latencytop.c  latencytop.gcno  Makefile

./sane_schedstat:

Makefile          sane_schedstat.gcda  sane_schedstat.o

sane_schedstat.c  sane_schedstat.gcno

./showmap:

Makefile  showmap.c  showmap.o

root@babu-VirtualBox:~/gcov_tests# 

• In case the test machine is different from the build machine, then an additional step of bringing the run time gcov information from test machine to build machine is required. I have automated this step using a script - https://github.com/babuneelam/gcov_scripts/blob/master/fetch_n_merge_gcov. One can use this script from build machine in any build sub-directory to update corresponding directory's run time coverage info from the test machine. Below is the usage info of this script. Use this with "--remote --uinfo" options. I am not doing this step now as my test & build machines are the same.

root@babu-VirtualBox:~/gcov_tests/lkm# ./fetch_n_merge_gcov 

Usage: fetch_n_merge_gcov --[local/remote] --kinfo --uinfo
                    [--kp <kdir_prefix>] [--up <udir_prefix>]

Execute this script from any build sub-directory to update
corresponding run time coverage info

root@babu-VirtualBox:~/gcov_tests/lkm#

• The, from my top build directory, I ran the following lcov commands:

root@babu-VirtualBox:~/gcov_tests# geninfo  . -o ./coverage.info

Found gcov version: 4.8.1

Scanning . for .gcda files ...

Found 2 data files in .

Processing latencytop/latencytop.gcda

Processing sane_schedstat/sane_schedstat.gcda

Finished .info-file creation

root@babu-VirtualBox:~/gcov_tests# 

root@babu-VirtualBox:~/gcov_tests# ls

bin  coverage.info  dump_gcov  latencytop  Makefile  sane_schedstat  showmap

root@babu-VirtualBox:~/gcov_tests# 

root@babu-VirtualBox:~/gcov_tests# genhtml -o ./lcov_data/ ./coverage.info

Reading data file ./coverage.info

Found 2 entries.

Found common filename prefix "/home/babu"

Writing .css and .png files.

Generating output.

Processing file gcov_tests/latencytop/latencytop.c

Processing file gcov_tests/sane_schedstat/sane_schedstat.c

Writing directory view page.

Overall coverage rate:

  lines......: 56.8% (155 of 273 lines)

  functions..: 69.6% (16 of 23 functions)

  branches...: 43.7% (52 of 119 branches)

root@babu-VirtualBox:~/gcov_tests# 

root@babu-VirtualBox:~/gcov_tests# ls -LR lcov_data/

lcov_data/:

amber.png    gcov_tests  index-sort-b.html  ruby.png

emerald.png  glass.png   index-sort-f.html  snow.png

gcov.css     index.html  index-sort-l.html  updown.png

lcov_data/gcov_tests:

latencytop  sane_schedstat

lcov_data/gcov_tests/latencytop:

index.html         index-sort-l.html              latencytop.c.gcov.html

index-sort-b.html  latencytop.c.func.html

index-sort-f.html  latencytop.c.func-sort-c.html

lcov_data/gcov_tests/sane_schedstat:

index.html         sane_schedstat.c.func.html

index-sort-b.html  sane_schedstat.c.func-sort-c.html

index-sort-f.html  sane_schedstat.c.gcov.html

index-sort-l.html

root@babu-VirtualBox:~/gcov_tests# 

• I used firefox to view code coverage information of my tests. 

root@babu-VirtualBox:~/gcov_tests# firefox ./lcov_data/index.html

• For reference, I hosted my code coverage results on my google drive - https://googledrive.com/host/0B4xkNcpT6Zbdb2gzZUlfOURJcTg/. Here is the top level screen:  

• Among the three applications I have, lcov report included only those applications instrumented with gcov. So, engineers should NOT be hasty in concluding the coverage information based on just lcov report, but should cautiously check whether all the code expected to be compiled with gocv flags is compiled so. Any code that is not compiled with gcov flags should be categorized "unknown coverage".

Hope this helps.