{"id":6,"date":"2012-03-31T16:21:00","date_gmt":"2012-03-31T23:21:00","guid":{"rendered":"http:\/\/samueldotj.com\/blog\/?p=6"},"modified":"2013-09-08T16:18:45","modified_gmt":"2013-09-08T23:18:45","slug":"gcov-internals-overview","status":"publish","type":"post","link":"http:\/\/samueldotj.com\/blog\/gcov-internals-overview\/","title":{"rendered":"Internals of GNU Code Coverage – gcov"},"content":{"rendered":"

Few years ago I worked on a small project to extract code coverage<\/a> information created by gcc from FreeBSD based kernel<\/a>. During that time I didn’t find any good internal documentation about gcov<\/a>. So here I post what I learned. Before jumping to the internals of GCOV here is an example from the man <\/a>page.<\/p>\n

\r\n$ gcov -b tmp.c\r\n87.50% of 8 source lines executed in file tmp.c\r\n80.00% of 5 branches executed in file tmp.c\r\n80.00% of 5 branches taken  at  least  once  in  file tmp.c\r\n50.00% of 2 calls executed in file tmp.c<\/span>\r\nCreating tmp.c.gcov.\r\nHere is a sample of a resulting tmp.c.gcov file:\r\n\r\n      main()\r\n      {\r\n    1<\/span>        int i, total;\r\n    1<\/span>        total = 0;\r\n   11<\/span>        for (i = 0; i < 10; i++)\r\nbranch 0 taken = 91%\r\nbranch 1 taken = 100%\r\nbranch 2 taken = 100%<\/span>\r\n   10<\/span>        total += i;\r\n   1<\/span>         if (total != 45)\r\nbranch 0 taken = 100%<\/span>\r\n  ######<\/span>          printf (\"Failure0);\r\ncall 0 never executed\r\nbranch 1 never executed<\/span>\r\n             else\r\n    1<\/span>             printf (\"Success0);\r\ncall 0 returns = 100%<\/span>\r\n    1<\/span>    }\r\n<\/pre>\n
Note – gcov has a cool graphical front-end in Linux – lcov<\/a>.
\nAs shown above gcov can show what all code path executed and how many time executed.
\nWant to try? Here is the quick example.
\n[shell]
\n$ gcc -fprofile-arcs -ftest-coverage your_program.c
\n$ .\/a.out
\n$ gcov your_program.c
\n[\/shell]<\/p>\n
During compilation with -ftest-coverage<\/a> option gcc generates a “.gcno”<\/a> file. It contains information about each branches in your code. While finishing execution, .\/a.out creates .gcda<\/b> file(s) which actually contains which all branches taken(basic block<\/a> entry\/exit). Using these there files .c(source), .gcno(block info) and .gcda(block execution count) gcov command prints the code coverage information in a human readable format.<\/p>\n
You might wonder how your .\/a.out would create .gcda while exiting the program. It is because of “-fprofile-arcs” automatically includes libgcov<\/a>. Libgcov registers itself to be invoked during program exit by using atexit()<\/a>. (Yes – it wont generate .gcda files if you exit abnormally). And during program exit<\/a> it just dumps all the branch information to one or more gcda file.<\/p>\n
The coverage information is “just” dumped into files by libgcov. So who collects the the coverage information at run time? Actually the program itself collects the coverage information. In-fact only it can collect because only it knew which all code path it takes. The code coverage information is collected at run-time<\/strong> on the fly. It is accomplished by having a counter for each branch. For example consider the following program.<\/p>\n
\r\nint if_counter = 0, else_counter = 0;<\/span>\r\n\r\nvoid dump_counters()\r\n{\r\n\tint fd;\r\n\t\r\n\tfd = open(strcat(filename, \".gcda\"), \"w\");\r\n\twrite(fd, if_counter, sizeof(if_counter));\r\n\twrite(fd, else_counter, sizeof(else_counter));\r\n}\r\n<\/span>\r\nint main(int argc, char *argv[])\r\n{\r\n\tatexit(dump_counters);<\/span>\r\n\t\r\n\tif(argc > 1) {\r\n\t\tif_counter++;<\/span>\r\n\t\tprintf(\"Arguments provided\\n\");\r\n\t} else {\r\n\t\telse_counter++;<\/span>\r\n\t\tprintf(\"No arguments\\n\");\r\n\t}\r\n}\r\n<\/pre>\n
If you replace the above example with gcov then green colored code is provided by libgcov(during link\/load) and the blue colored coded inserted into your executable by gcc(during compilation).<\/p>\n
Here is a simple C program’s disassembly:
\n[codegroup]
\n[c tab=’disassembly’]
\nint main()
\n{
\n  4004b4:       55                      push   %rbp
\n  4004b5:       48 89 e5                mov    %rsp,%rbp
\n    int a = 1;
\n  4004b8:       c7 45 fc 01 00 00 00    movl   $0x1,-0x4(%rbp)<\/p>\n
    if (a) {
\n  4004bf:       83 7d fc 00             cmpl   $0x0,-0x4(%rbp)
\n  4004c3:       74 06                   je     4004cb 
\n        a++;
\n  4004c5:       83 45 fc 01             addl   $0x1,-0x4(%rbp)
\n  4004c9:       eb 04                   jmp    4004cf 
\n    } else {
\n        a–;
\n  4004cb:       83 6d fc 01             subl   $0x1,-0x4(%rbp)
\n    }<\/p>\n
    return a;
\n  4004cf:       8b 45 fc                mov    -0x4(%rbp),%eax
\n}
\n[\/c]<\/p>\n
[c tab=’source’]
\nint main()
\n{
\n    int a = 1;<\/p>\n
    if (a) {
\n        a++;
\n    } else {
\n        a–;
\n    }<\/p>\n
    return a;
\n}
\n[\/c]<\/p>\n
[shell tab=’command’]
\ngcc -g3 test.c
\nobjdump -S -d .\/a.out
\n[\/shell]<\/p>\n
[\/codegroup]<\/p>\n
When the same program compiled with profile-arcs<\/strong>, the disassembly looks like<\/p>\n
\r\nint main()\r\n{\r\n  400c34:       55                      push   %rbp\r\n  400c35:       48 89 e5                mov    %rsp,%rbp\r\n  400c38:       48 83 ec 10             sub    $0x10,%rsp\r\n    int a = 1;\r\n  400c3c:       c7 45 fc 01 00 00 00    movl   $0x1,-0x4(%rbp)\r\n\r\n    if (a) {\r\n  400c43:       83 7d fc 00             cmpl   $0x0,-0x4(%rbp)\r\n  400c47:       74 18                   je     400c61 \r\n        a++;\r\n  400c49:       83 45 fc 01             addl   $0x1,-0x4(%rbp)\r\n  400c4d:       48 8b 05 3c 25 20 00    mov    0x20253c(%rip),%rax        # 603190 \r\n  400c54:       48 83 c0 01             add    $0x1,%rax\r\n  400c58:       48 89 05 31 25 20 00    mov    %rax,0x202531(%rip)        # 603190 <\/span>\r\n  400c5f:       eb 16                   jmp    400c77 \r\n    } else {\r\n        a--;\r\n  400c61:       83 6d fc 01             subl   $0x1,-0x4(%rbp)\r\n  400c65:       48 8b 05 2c 25 20 00    mov    0x20252c(%rip),%rax        # 603198 \r\n  400c6c:       48 83 c0 01             add    $0x1,%rax\r\n  400c70:       48 89 05 21 25 20 00    mov    %rax,0x202521(%rip)        # 603198 <\/span>\r\n    }\r\n\r\n    return a;\r\n  400c77:       8b 45 fc                mov    -0x4(%rbp),%eax\r\n}\r\n  400c7a:       c9                      leaveq\r\n  400c7b:       c3                      retq\r\n<\/pre>\n
From the above disassembly it might seem putting inc instruction while compiling is easy. But how\/where storage for the counters(dtor_idx.6460 and dtor_idx.6460 in above example) are created. GCC uses statically allocated memory. Dynamically allocating space is one way but it would complicate the code(memory allocation operations during init) and might slow down execution of program(defer pointer). To avoid that gcc allocates storage as a loadable section.<\/p>\n
Generic C constructor<\/strong>:
\ngcc generates constructors for all program. C constructors are accomplished by using “.ctors” section of ELF file. This section contains array of function pointers. This array is iterated and each function is invoked by _init()->__do_global_ctors_aux() during program start. _init() is placed “.init” section so it will be called during program initialization. A function can be declared as constructor by using function attribute<\/a>.<\/p>\n
“-ftest-coverage” creates a constructor per file. This constructor calls __gcov_init() and passes the gcov_info as argument.<\/p>\n
\r\nsamuel@ubuntu:~$objdump  -t .\/a.out  | grep -i _GLOBAL__\r\n0000000000400c7c l     F .text  0000000000000010              _GLOBAL__sub_I_65535_0_main\r\n<\/pre>\n
And disassembly of _GLOBAL__sub_I_65535_0_main<\/p>\n
\r\n 954 0000000000400c7c <_global__sub_i_65535_0_main>:\r\n 955   400c7c:       55                      push   %rbp\r\n 956   400c7d:       48 89 e5                mov    %rsp,%rbp\r\n 957   400c80:       bf 00 31 60 00          mov    $0x603100,%edi\r\n 958   400c85:       e8 a6 12 00 00          callq  401f30 <__gcov_init>\r\n 959   400c8a:       5d                      pop    %rbp\r\n 960   400c8b:       c3                      retq\r\n 961   400c8c:       90                      nop\r\n 962   400c8d:       90                      nop\r\n 963   400c8e:       90                      nop\r\n 964   400c8f:       90                      nop\r\n<\/__gcov_init><\/_global__sub_i_65535_0_main><\/pre>\n
gcov_init() implemented in libgcov stores all the gcov_info() passed in a linked list. This linked list is used to walk through all the gcov_info during program termination.<\/p>\n","protected":false},"excerpt":{"rendered":"
Few years ago I worked on a small project to extract code coverage information created by gcc from FreeBSD based kernel. During that time I didn’t find any good internal documentation about gcov. So here I post what I learned. Before jumping to the internals of GCOV here is an example from the man page. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,9,4],"tags":[],"class_list":["post-6","post","type-post","status-publish","format-standard","hentry","category-c","category-gcc","category-tools"],"_links":{"self":[{"href":"http:\/\/samueldotj.com\/blog\/wp-json\/wp\/v2\/posts\/6","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/samueldotj.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/samueldotj.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/samueldotj.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/samueldotj.com\/blog\/wp-json\/wp\/v2\/comments?post=6"}],"version-history":[{"count":5,"href":"http:\/\/samueldotj.com\/blog\/wp-json\/wp\/v2\/posts\/6\/revisions"}],"predecessor-version":[{"id":225,"href":"http:\/\/samueldotj.com\/blog\/wp-json\/wp\/v2\/posts\/6\/revisions\/225"}],"wp:attachment":[{"href":"http:\/\/samueldotj.com\/blog\/wp-json\/wp\/v2\/media?parent=6"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/samueldotj.com\/blog\/wp-json\/wp\/v2\/categories?post=6"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/samueldotj.com\/blog\/wp-json\/wp\/v2\/tags?post=6"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
The compiler keep tracks of all the counters in a single file. The data structure outlined in the below picture.
\n\"gcov\"<\/a>
\nThere is a single gcov_info structure for a C file. And multiple gcov_fn_info and gcov_ctr_info. During program exit() these structures are dumped into the .gcda file. For a project(with multiple C files) each C file will have a gcov_info structure. These gcov_info structures should be linked together so that during exit() the program can generate .gcda file for all the C files. This is done by using constructors and destructors.<\/p>\n
It is easy to speculate how the increment operation would be be implanted inside your code by gcc. gcc just inserts “inc x-counter<\/i>“<\/b> machine instruction before and after every branch. It should be noted that “inc” is instruction might have side effect on some programs which uses asm inside C. For example in x86 the “inc<\/a>” instruction affects carry flag<\/a>. Some assembly code might depends on this and if gcc inserts “inc counter” instruction then it will result in error. I had hard time figuring this out when compiled with -fprofile-arcs a kernel was booting but not able to receive any network packets(it was discarding all packets because the network stack found the checksum<\/a> was wrong).<\/p>\n