1 | @c Copyright (C) 1996, 1997 Free Software Foundation, Inc. |
---|
2 | @c This is part of the GCC manual. |
---|
3 | @c For copying conditions, see the file gcc.texi. |
---|
4 | |
---|
5 | @node Gcov |
---|
6 | @chapter @code{gcov}: a Test Coverage Program |
---|
7 | |
---|
8 | @code{gcov} is a tool you can use in conjunction with @sc{gnu} CC to |
---|
9 | test code coverage in your programs. |
---|
10 | |
---|
11 | This chapter describes version 1.5 of @code{gcov}. |
---|
12 | |
---|
13 | @menu |
---|
14 | * Gcov Intro:: Introduction to gcov. |
---|
15 | * Invoking Gcov:: How to use gcov. |
---|
16 | * Gcov and Optimization:: Using gcov with GCC optimization. |
---|
17 | * Gcov Data Files:: The files used by gcov. |
---|
18 | @end menu |
---|
19 | |
---|
20 | @node Gcov Intro |
---|
21 | @section Introduction to @code{gcov} |
---|
22 | |
---|
23 | @code{gcov} is a test coverage program. Use it in concert with @sc{gnu} |
---|
24 | CC to analyze your programs to help create more efficient, faster |
---|
25 | running code. You can use @code{gcov} as a profiling tool to help |
---|
26 | discover where your optimization efforts will best affect your code. You |
---|
27 | can also use @code{gcov} along with the other profiling tool, |
---|
28 | @code{gprof}, to assess which parts of your code use the greatest amount |
---|
29 | of computing time. |
---|
30 | |
---|
31 | Profiling tools help you analyze your code's performance. Using a |
---|
32 | profiler such as @code{gcov} or @code{gprof}, you can find out some |
---|
33 | basic performance statistics, such as: |
---|
34 | |
---|
35 | @itemize @bullet |
---|
36 | @item |
---|
37 | how often each line of code executes |
---|
38 | |
---|
39 | @item |
---|
40 | what lines of code are actually executed |
---|
41 | |
---|
42 | @item |
---|
43 | how much computing time each section of code uses |
---|
44 | @end itemize |
---|
45 | |
---|
46 | Once you know these things about how your code works when compiled, you |
---|
47 | can look at each module to see which modules should be optimized. |
---|
48 | @code{gcov} helps you determine where to work on optimization. |
---|
49 | |
---|
50 | Software developers also use coverage testing in concert with |
---|
51 | testsuites, to make sure software is actually good enough for a release. |
---|
52 | Testsuites can verify that a program works as expected; a coverage |
---|
53 | program tests to see how much of the program is exercised by the |
---|
54 | testsuite. Developers can then determine what kinds of test cases need |
---|
55 | to be added to the testsuites to create both better testing and a better |
---|
56 | final product. |
---|
57 | |
---|
58 | You should compile your code without optimization if you plan to use |
---|
59 | @code{gcov} because the optimization, by combining some lines of code |
---|
60 | into one function, may not give you as much information as you need to |
---|
61 | look for `hot spots' where the code is using a great deal of computer |
---|
62 | time. Likewise, because @code{gcov} accumulates statistics by line (at |
---|
63 | the lowest resolution), it works best with a programming style that |
---|
64 | places only one statement on each line. If you use complicated macros |
---|
65 | that expand to loops or to other control structures, the statistics are |
---|
66 | less helpful---they only report on the line where the macro call |
---|
67 | appears. If your complex macros behave like functions, you can replace |
---|
68 | them with inline functions to solve this problem. |
---|
69 | |
---|
70 | @code{gcov} creates a logfile called @file{@var{sourcefile}.gcov} which |
---|
71 | indicates how many times each line of a source file @file{@var{sourcefile}.c} |
---|
72 | has executed. You can use these logfiles along with @code{gprof} to aid |
---|
73 | in fine-tuning the performance of your programs. @code{gprof} gives |
---|
74 | timing information you can use along with the information you get from |
---|
75 | @code{gcov}. |
---|
76 | |
---|
77 | @code{gcov} works only on code compiled with @sc{gnu} CC. It is not |
---|
78 | compatible with any other profiling or test coverage mechanism. |
---|
79 | |
---|
80 | @node Invoking Gcov |
---|
81 | @section Invoking gcov |
---|
82 | |
---|
83 | @smallexample |
---|
84 | gcov [-b] [-v] [-n] [-l] [-f] [-o directory] @var{sourcefile} |
---|
85 | @end smallexample |
---|
86 | |
---|
87 | @table @code |
---|
88 | @item -b |
---|
89 | Write branch frequencies to the output file, and write branch summary |
---|
90 | info to the standard output. This option allows you to see how often |
---|
91 | each branch in your program was taken. |
---|
92 | |
---|
93 | @item -v |
---|
94 | Display the @code{gcov} version number (on the standard error stream). |
---|
95 | |
---|
96 | @item -n |
---|
97 | Do not create the @code{gcov} output file. |
---|
98 | |
---|
99 | @item -l |
---|
100 | Create long file names for included source files. For example, if the |
---|
101 | header file @samp{x.h} contains code, and was included in the file |
---|
102 | @samp{a.c}, then running @code{gcov} on the file @samp{a.c} will produce |
---|
103 | an output file called @samp{a.c.x.h.gcov} instead of @samp{x.h.gcov}. |
---|
104 | This can be useful if @samp{x.h} is included in multiple source files. |
---|
105 | |
---|
106 | @item -f |
---|
107 | Output summaries for each function in addition to the file level summary. |
---|
108 | |
---|
109 | @item -o |
---|
110 | The directory where the object files live. Gcov will search for @code{.bb}, |
---|
111 | @code{.bbg}, and @code{.da} files in this directory. |
---|
112 | @end table |
---|
113 | |
---|
114 | @need 3000 |
---|
115 | When using @code{gcov}, you must first compile your program with two |
---|
116 | special @sc{gnu} CC options: @samp{-fprofile-arcs -ftest-coverage}. |
---|
117 | This tells the compiler to generate additional information needed by |
---|
118 | gcov (basically a flow graph of the program) and also includes |
---|
119 | additional code in the object files for generating the extra profiling |
---|
120 | information needed by gcov. These additional files are placed in the |
---|
121 | directory where the source code is located. |
---|
122 | |
---|
123 | Running the program will cause profile output to be generated. For each |
---|
124 | source file compiled with -fprofile-arcs, an accompanying @code{.da} |
---|
125 | file will be placed in the source directory. |
---|
126 | |
---|
127 | Running @code{gcov} with your program's source file names as arguments |
---|
128 | will now produce a listing of the code along with frequency of execution |
---|
129 | for each line. For example, if your program is called @samp{tmp.c}, this |
---|
130 | is what you see when you use the basic @code{gcov} facility: |
---|
131 | |
---|
132 | @smallexample |
---|
133 | $ gcc -fprofile-arcs -ftest-coverage tmp.c |
---|
134 | $ a.out |
---|
135 | $ gcov tmp.c |
---|
136 | 87.50% of 8 source lines executed in file tmp.c |
---|
137 | Creating tmp.c.gcov. |
---|
138 | @end smallexample |
---|
139 | |
---|
140 | The file @file{tmp.c.gcov} contains output from @code{gcov}. |
---|
141 | Here is a sample: |
---|
142 | |
---|
143 | @smallexample |
---|
144 | main() |
---|
145 | @{ |
---|
146 | 1 int i, total; |
---|
147 | |
---|
148 | 1 total = 0; |
---|
149 | |
---|
150 | 11 for (i = 0; i < 10; i++) |
---|
151 | 10 total += i; |
---|
152 | |
---|
153 | 1 if (total != 45) |
---|
154 | ###### printf ("Failure\n"); |
---|
155 | else |
---|
156 | 1 printf ("Success\n"); |
---|
157 | 1 @} |
---|
158 | @end smallexample |
---|
159 | |
---|
160 | @need 450 |
---|
161 | When you use the @samp{-b} option, your output looks like this: |
---|
162 | |
---|
163 | @smallexample |
---|
164 | $ gcov -b tmp.c |
---|
165 | 87.50% of 8 source lines executed in file tmp.c |
---|
166 | 80.00% of 5 branches executed in file tmp.c |
---|
167 | 80.00% of 5 branches taken at least once in file tmp.c |
---|
168 | 50.00% of 2 calls executed in file tmp.c |
---|
169 | Creating tmp.c.gcov. |
---|
170 | @end smallexample |
---|
171 | |
---|
172 | Here is a sample of a resulting @file{tmp.c.gcov} file: |
---|
173 | |
---|
174 | @smallexample |
---|
175 | main() |
---|
176 | @{ |
---|
177 | 1 int i, total; |
---|
178 | |
---|
179 | 1 total = 0; |
---|
180 | |
---|
181 | 11 for (i = 0; i < 10; i++) |
---|
182 | branch 0 taken = 91% |
---|
183 | branch 1 taken = 100% |
---|
184 | branch 2 taken = 100% |
---|
185 | 10 total += i; |
---|
186 | |
---|
187 | 1 if (total != 45) |
---|
188 | branch 0 taken = 100% |
---|
189 | ###### printf ("Failure\n"); |
---|
190 | call 0 never executed |
---|
191 | branch 1 never executed |
---|
192 | else |
---|
193 | 1 printf ("Success\n"); |
---|
194 | call 0 returns = 100% |
---|
195 | 1 @} |
---|
196 | @end smallexample |
---|
197 | |
---|
198 | For each basic block, a line is printed after the last line of the basic |
---|
199 | block describing the branch or call that ends the basic block. There can |
---|
200 | be multiple branches and calls listed for a single source line if there |
---|
201 | are multiple basic blocks that end on that line. In this case, the |
---|
202 | branches and calls are each given a number. There is no simple way to map |
---|
203 | these branches and calls back to source constructs. In general, though, |
---|
204 | the lowest numbered branch or call will correspond to the leftmost construct |
---|
205 | on the source line. |
---|
206 | |
---|
207 | For a branch, if it was executed at least once, then a percentage |
---|
208 | indicating the number of times the branch was taken divided by the |
---|
209 | number of times the branch was executed will be printed. Otherwise, the |
---|
210 | message ``never executed'' is printed. |
---|
211 | |
---|
212 | For a call, if it was executed at least once, then a percentage |
---|
213 | indicating the number of times the call returned divided by the number |
---|
214 | of times the call was executed will be printed. This will usually be |
---|
215 | 100%, but may be less for functions call @code{exit} or @code{longjmp}, |
---|
216 | and thus may not return everytime they are called. |
---|
217 | |
---|
218 | The execution counts are cumulative. If the example program were |
---|
219 | executed again without removing the @code{.da} file, the count for the |
---|
220 | number of times each line in the source was executed would be added to |
---|
221 | the results of the previous run(s). This is potentially useful in |
---|
222 | several ways. For example, it could be used to accumulate data over a |
---|
223 | number of program runs as part of a test verification suite, or to |
---|
224 | provide more accurate long-term information over a large number of |
---|
225 | program runs. |
---|
226 | |
---|
227 | The data in the @code{.da} files is saved immediately before the program |
---|
228 | exits. For each source file compiled with -fprofile-arcs, the profiling |
---|
229 | code first attempts to read in an existing @code{.da} file; if the file |
---|
230 | doesn't match the executable (differing number of basic block counts) it |
---|
231 | will ignore the contents of the file. It then adds in the new execution |
---|
232 | counts and finally writes the data to the file. |
---|
233 | |
---|
234 | @node Gcov and Optimization |
---|
235 | @section Using @code{gcov} with GCC Optimization |
---|
236 | |
---|
237 | If you plan to use @code{gcov} to help optimize your code, you must |
---|
238 | first compile your program with two special @sc{gnu} CC options: |
---|
239 | @samp{-fprofile-arcs -ftest-coverage}. Aside from that, you can use any |
---|
240 | other @sc{gnu} CC options; but if you want to prove that every single line |
---|
241 | in your program was executed, you should not compile with optimization |
---|
242 | at the same time. On some machines the optimizer can eliminate some |
---|
243 | simple code lines by combining them with other lines. For example, code |
---|
244 | like this: |
---|
245 | |
---|
246 | @smallexample |
---|
247 | if (a != b) |
---|
248 | c = 1; |
---|
249 | else |
---|
250 | c = 0; |
---|
251 | @end smallexample |
---|
252 | |
---|
253 | @noindent |
---|
254 | can be compiled into one instruction on some machines. In this case, |
---|
255 | there is no way for @code{gcov} to calculate separate execution counts |
---|
256 | for each line because there isn't separate code for each line. Hence |
---|
257 | the @code{gcov} output looks like this if you compiled the program with |
---|
258 | optimization: |
---|
259 | |
---|
260 | @smallexample |
---|
261 | 100 if (a != b) |
---|
262 | 100 c = 1; |
---|
263 | 100 else |
---|
264 | 100 c = 0; |
---|
265 | @end smallexample |
---|
266 | |
---|
267 | The output shows that this block of code, combined by optimization, |
---|
268 | executed 100 times. In one sense this result is correct, because there |
---|
269 | was only one instruction representing all four of these lines. However, |
---|
270 | the output does not indicate how many times the result was 0 and how |
---|
271 | many times the result was 1. |
---|
272 | |
---|
273 | @node Gcov Data Files |
---|
274 | @section Brief description of @code{gcov} data files |
---|
275 | |
---|
276 | @code{gcov} uses three files for doing profiling. The names of these |
---|
277 | files are derived from the original @emph{source} file by substituting |
---|
278 | the file suffix with either @code{.bb}, @code{.bbg}, or @code{.da}. All |
---|
279 | of these files are placed in the same directory as the source file, and |
---|
280 | contain data stored in a platform-independent method. |
---|
281 | |
---|
282 | The @code{.bb} and @code{.bbg} files are generated when the source file |
---|
283 | is compiled with the @sc{gnu} CC @samp{-ftest-coverage} option. The |
---|
284 | @code{.bb} file contains a list of source files (including headers), |
---|
285 | functions within those files, and line numbers corresponding to each |
---|
286 | basic block in the source file. |
---|
287 | |
---|
288 | The @code{.bb} file format consists of several lists of 4-byte integers |
---|
289 | which correspond to the line numbers of each basic block in the |
---|
290 | file. Each list is terminated by a line number of 0. A line number of -1 |
---|
291 | is used to designate that the source file name (padded to a 4-byte |
---|
292 | boundary and followed by another -1) follows. In addition, a line number |
---|
293 | of -2 is used to designate that the name of a function (also padded to a |
---|
294 | 4-byte boundary and followed by a -2) follows. |
---|
295 | |
---|
296 | The @code{.bbg} file is used to reconstruct the program flow graph for |
---|
297 | the source file. It contains a list of the program flow arcs (possible |
---|
298 | branches taken from one basic block to another) for each function which, |
---|
299 | in combination with the @code{.bb} file, enables gcov to reconstruct the |
---|
300 | program flow. |
---|
301 | |
---|
302 | In the @code{.bbg} file, the format is: |
---|
303 | @smallexample |
---|
304 | number of basic blocks for function #0 (4-byte number) |
---|
305 | total number of arcs for function #0 (4-byte number) |
---|
306 | count of arcs in basic block #0 (4-byte number) |
---|
307 | destination basic block of arc #0 (4-byte number) |
---|
308 | flag bits (4-byte number) |
---|
309 | destination basic block of arc #1 (4-byte number) |
---|
310 | flag bits (4-byte number) |
---|
311 | ... |
---|
312 | destination basic block of arc #N (4-byte number) |
---|
313 | flag bits (4-byte number) |
---|
314 | count of arcs in basic block #1 (4-byte number) |
---|
315 | destination basic block of arc #0 (4-byte number) |
---|
316 | flag bits (4-byte number) |
---|
317 | ... |
---|
318 | @end smallexample |
---|
319 | |
---|
320 | A -1 (stored as a 4-byte number) is used to separate each function's |
---|
321 | list of basic blocks, and to verify that the file has been read |
---|
322 | correctly. |
---|
323 | |
---|
324 | The @code{.da} file is generated when a program containing object files |
---|
325 | built with the @sc{gnu} CC @samp{-fprofile-arcs} option is executed. A |
---|
326 | separate @code{.da} file is created for each source file compiled with |
---|
327 | this option, and the name of the @code{.da} file is stored as an |
---|
328 | absolute pathname in the resulting object file. This path name is |
---|
329 | derived from the source file name by substituting a @code{.da} suffix. |
---|
330 | |
---|
331 | The format of the @code{.da} file is fairly simple. The first 8-byte |
---|
332 | number is the number of counts in the file, followed by the counts |
---|
333 | (stored as 8-byte numbers). Each count corresponds to the number of |
---|
334 | times each arc in the program is executed. The counts are cumulative; |
---|
335 | each time the program is executed, it attemps to combine the existing |
---|
336 | @code{.da} files with the new counts for this invocation of the |
---|
337 | program. It ignores the contents of any @code{.da} files whose number of |
---|
338 | arcs doesn't correspond to the current program, and merely overwrites |
---|
339 | them instead. |
---|
340 | |
---|
341 | All three of these files use the functions in @code{gcov-io.h} to store |
---|
342 | integers; the functions in this header provide a machine-independent |
---|
343 | mechanism for storing and retrieving data from a stream. |
---|
344 | |
---|