Mercurial > hg > CbC > CbC_gcc
comparison gcc/doc/gcov.texi @ 0:a06113de4d67
first commit
author | kent <kent@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Fri, 17 Jul 2009 14:47:48 +0900 |
parents | |
children | f6334be47118 |
comparison
equal
deleted
inserted
replaced
-1:000000000000 | 0:a06113de4d67 |
---|---|
1 @c Copyright (C) 1996, 1997, 1999, 2000, 2001, | |
2 @c 2002, 2003, 2004, 2005, 2008 Free Software Foundation, Inc. | |
3 @c This is part of the GCC manual. | |
4 @c For copying conditions, see the file gcc.texi. | |
5 | |
6 @ignore | |
7 @c man begin COPYRIGHT | |
8 Copyright @copyright{} 1996, 1997, 1999, 2000, 2001, 2002, 2003, 2004, 2005, | |
9 2008 Free Software Foundation, Inc. | |
10 | |
11 Permission is granted to copy, distribute and/or modify this document | |
12 under the terms of the GNU Free Documentation License, Version 1.2 or | |
13 any later version published by the Free Software Foundation; with the | |
14 Invariant Sections being ``GNU General Public License'' and ``Funding | |
15 Free Software'', the Front-Cover texts being (a) (see below), and with | |
16 the Back-Cover Texts being (b) (see below). A copy of the license is | |
17 included in the gfdl(7) man page. | |
18 | |
19 (a) The FSF's Front-Cover Text is: | |
20 | |
21 A GNU Manual | |
22 | |
23 (b) The FSF's Back-Cover Text is: | |
24 | |
25 You have freedom to copy and modify this GNU Manual, like GNU | |
26 software. Copies published by the Free Software Foundation raise | |
27 funds for GNU development. | |
28 @c man end | |
29 @c Set file name and title for the man page. | |
30 @setfilename gcov | |
31 @settitle coverage testing tool | |
32 @end ignore | |
33 | |
34 @node Gcov | |
35 @chapter @command{gcov}---a Test Coverage Program | |
36 | |
37 @command{gcov} is a tool you can use in conjunction with GCC to | |
38 test code coverage in your programs. | |
39 | |
40 @menu | |
41 * Gcov Intro:: Introduction to gcov. | |
42 * Invoking Gcov:: How to use gcov. | |
43 * Gcov and Optimization:: Using gcov with GCC optimization. | |
44 * Gcov Data Files:: The files used by gcov. | |
45 * Cross-profiling:: Data file relocation. | |
46 @end menu | |
47 | |
48 @node Gcov Intro | |
49 @section Introduction to @command{gcov} | |
50 @c man begin DESCRIPTION | |
51 | |
52 @command{gcov} is a test coverage program. Use it in concert with GCC | |
53 to analyze your programs to help create more efficient, faster running | |
54 code and to discover untested parts of your program. You can use | |
55 @command{gcov} as a profiling tool to help discover where your | |
56 optimization efforts will best affect your code. You can also use | |
57 @command{gcov} along with the other profiling tool, @command{gprof}, to | |
58 assess which parts of your code use the greatest amount of computing | |
59 time. | |
60 | |
61 Profiling tools help you analyze your code's performance. Using a | |
62 profiler such as @command{gcov} or @command{gprof}, you can find out some | |
63 basic performance statistics, such as: | |
64 | |
65 @itemize @bullet | |
66 @item | |
67 how often each line of code executes | |
68 | |
69 @item | |
70 what lines of code are actually executed | |
71 | |
72 @item | |
73 how much computing time each section of code uses | |
74 @end itemize | |
75 | |
76 Once you know these things about how your code works when compiled, you | |
77 can look at each module to see which modules should be optimized. | |
78 @command{gcov} helps you determine where to work on optimization. | |
79 | |
80 Software developers also use coverage testing in concert with | |
81 testsuites, to make sure software is actually good enough for a release. | |
82 Testsuites can verify that a program works as expected; a coverage | |
83 program tests to see how much of the program is exercised by the | |
84 testsuite. Developers can then determine what kinds of test cases need | |
85 to be added to the testsuites to create both better testing and a better | |
86 final product. | |
87 | |
88 You should compile your code without optimization if you plan to use | |
89 @command{gcov} because the optimization, by combining some lines of code | |
90 into one function, may not give you as much information as you need to | |
91 look for `hot spots' where the code is using a great deal of computer | |
92 time. Likewise, because @command{gcov} accumulates statistics by line (at | |
93 the lowest resolution), it works best with a programming style that | |
94 places only one statement on each line. If you use complicated macros | |
95 that expand to loops or to other control structures, the statistics are | |
96 less helpful---they only report on the line where the macro call | |
97 appears. If your complex macros behave like functions, you can replace | |
98 them with inline functions to solve this problem. | |
99 | |
100 @command{gcov} creates a logfile called @file{@var{sourcefile}.gcov} which | |
101 indicates how many times each line of a source file @file{@var{sourcefile}.c} | |
102 has executed. You can use these logfiles along with @command{gprof} to aid | |
103 in fine-tuning the performance of your programs. @command{gprof} gives | |
104 timing information you can use along with the information you get from | |
105 @command{gcov}. | |
106 | |
107 @command{gcov} works only on code compiled with GCC@. It is not | |
108 compatible with any other profiling or test coverage mechanism. | |
109 | |
110 @c man end | |
111 | |
112 @node Invoking Gcov | |
113 @section Invoking @command{gcov} | |
114 | |
115 @smallexample | |
116 gcov @r{[}@var{options}@r{]} @var{sourcefiles} | |
117 @end smallexample | |
118 | |
119 @command{gcov} accepts the following options: | |
120 | |
121 @ignore | |
122 @c man begin SYNOPSIS | |
123 gcov [@option{-v}|@option{--version}] [@option{-h}|@option{--help}] | |
124 [@option{-a}|@option{--all-blocks}] | |
125 [@option{-b}|@option{--branch-probabilities}] | |
126 [@option{-c}|@option{--branch-counts}] | |
127 [@option{-n}|@option{--no-output}] | |
128 [@option{-l}|@option{--long-file-names}] | |
129 [@option{-p}|@option{--preserve-paths}] | |
130 [@option{-f}|@option{--function-summaries}] | |
131 [@option{-o}|@option{--object-directory} @var{directory|file}] @var{sourcefiles} | |
132 [@option{-u}|@option{--unconditional-branches}] | |
133 @c man end | |
134 @c man begin SEEALSO | |
135 gpl(7), gfdl(7), fsf-funding(7), gcc(1) and the Info entry for @file{gcc}. | |
136 @c man end | |
137 @end ignore | |
138 | |
139 @c man begin OPTIONS | |
140 @table @gcctabopt | |
141 @item -h | |
142 @itemx --help | |
143 Display help about using @command{gcov} (on the standard output), and | |
144 exit without doing any further processing. | |
145 | |
146 @item -v | |
147 @itemx --version | |
148 Display the @command{gcov} version number (on the standard output), | |
149 and exit without doing any further processing. | |
150 | |
151 @item -a | |
152 @itemx --all-blocks | |
153 Write individual execution counts for every basic block. Normally gcov | |
154 outputs execution counts only for the main blocks of a line. With this | |
155 option you can determine if blocks within a single line are not being | |
156 executed. | |
157 | |
158 @item -b | |
159 @itemx --branch-probabilities | |
160 Write branch frequencies to the output file, and write branch summary | |
161 info to the standard output. This option allows you to see how often | |
162 each branch in your program was taken. Unconditional branches will not | |
163 be shown, unless the @option{-u} option is given. | |
164 | |
165 @item -c | |
166 @itemx --branch-counts | |
167 Write branch frequencies as the number of branches taken, rather than | |
168 the percentage of branches taken. | |
169 | |
170 @item -n | |
171 @itemx --no-output | |
172 Do not create the @command{gcov} output file. | |
173 | |
174 @item -l | |
175 @itemx --long-file-names | |
176 Create long file names for included source files. For example, if the | |
177 header file @file{x.h} contains code, and was included in the file | |
178 @file{a.c}, then running @command{gcov} on the file @file{a.c} will produce | |
179 an output file called @file{a.c##x.h.gcov} instead of @file{x.h.gcov}. | |
180 This can be useful if @file{x.h} is included in multiple source | |
181 files. If you use the @samp{-p} option, both the including and | |
182 included file names will be complete path names. | |
183 | |
184 @item -p | |
185 @itemx --preserve-paths | |
186 Preserve complete path information in the names of generated | |
187 @file{.gcov} files. Without this option, just the filename component is | |
188 used. With this option, all directories are used, with @samp{/} characters | |
189 translated to @samp{#} characters, @file{.} directory components | |
190 removed and @file{..} | |
191 components renamed to @samp{^}. This is useful if sourcefiles are in several | |
192 different directories. It also affects the @samp{-l} option. | |
193 | |
194 @item -f | |
195 @itemx --function-summaries | |
196 Output summaries for each function in addition to the file level summary. | |
197 | |
198 @item -o @var{directory|file} | |
199 @itemx --object-directory @var{directory} | |
200 @itemx --object-file @var{file} | |
201 Specify either the directory containing the gcov data files, or the | |
202 object path name. The @file{.gcno}, and | |
203 @file{.gcda} data files are searched for using this option. If a directory | |
204 is specified, the data files are in that directory and named after the | |
205 source file name, without its extension. If a file is specified here, | |
206 the data files are named after that file, without its extension. If this | |
207 option is not supplied, it defaults to the current directory. | |
208 | |
209 @item -u | |
210 @itemx --unconditional-branches | |
211 When branch probabilities are given, include those of unconditional branches. | |
212 Unconditional branches are normally not interesting. | |
213 | |
214 @end table | |
215 | |
216 @command{gcov} should be run with the current directory the same as that | |
217 when you invoked the compiler. Otherwise it will not be able to locate | |
218 the source files. @command{gcov} produces files called | |
219 @file{@var{mangledname}.gcov} in the current directory. These contain | |
220 the coverage information of the source file they correspond to. | |
221 One @file{.gcov} file is produced for each source file containing code, | |
222 which was compiled to produce the data files. The @var{mangledname} part | |
223 of the output file name is usually simply the source file name, but can | |
224 be something more complicated if the @samp{-l} or @samp{-p} options are | |
225 given. Refer to those options for details. | |
226 | |
227 The @file{.gcov} files contain the @samp{:} separated fields along with | |
228 program source code. The format is | |
229 | |
230 @smallexample | |
231 @var{execution_count}:@var{line_number}:@var{source line text} | |
232 @end smallexample | |
233 | |
234 Additional block information may succeed each line, when requested by | |
235 command line option. The @var{execution_count} is @samp{-} for lines | |
236 containing no code and @samp{#####} for lines which were never executed. | |
237 Some lines of information at the start have @var{line_number} of zero. | |
238 | |
239 The preamble lines are of the form | |
240 | |
241 @smallexample | |
242 -:0:@var{tag}:@var{value} | |
243 @end smallexample | |
244 | |
245 The ordering and number of these preamble lines will be augmented as | |
246 @command{gcov} development progresses --- do not rely on them remaining | |
247 unchanged. Use @var{tag} to locate a particular preamble line. | |
248 | |
249 The additional block information is of the form | |
250 | |
251 @smallexample | |
252 @var{tag} @var{information} | |
253 @end smallexample | |
254 | |
255 The @var{information} is human readable, but designed to be simple | |
256 enough for machine parsing too. | |
257 | |
258 When printing percentages, 0% and 100% are only printed when the values | |
259 are @emph{exactly} 0% and 100% respectively. Other values which would | |
260 conventionally be rounded to 0% or 100% are instead printed as the | |
261 nearest non-boundary value. | |
262 | |
263 When using @command{gcov}, you must first compile your program with two | |
264 special GCC options: @samp{-fprofile-arcs -ftest-coverage}. | |
265 This tells the compiler to generate additional information needed by | |
266 gcov (basically a flow graph of the program) and also includes | |
267 additional code in the object files for generating the extra profiling | |
268 information needed by gcov. These additional files are placed in the | |
269 directory where the object file is located. | |
270 | |
271 Running the program will cause profile output to be generated. For each | |
272 source file compiled with @option{-fprofile-arcs}, an accompanying | |
273 @file{.gcda} file will be placed in the object file directory. | |
274 | |
275 Running @command{gcov} with your program's source file names as arguments | |
276 will now produce a listing of the code along with frequency of execution | |
277 for each line. For example, if your program is called @file{tmp.c}, this | |
278 is what you see when you use the basic @command{gcov} facility: | |
279 | |
280 @smallexample | |
281 $ gcc -fprofile-arcs -ftest-coverage tmp.c | |
282 $ a.out | |
283 $ gcov tmp.c | |
284 90.00% of 10 source lines executed in file tmp.c | |
285 Creating tmp.c.gcov. | |
286 @end smallexample | |
287 | |
288 The file @file{tmp.c.gcov} contains output from @command{gcov}. | |
289 Here is a sample: | |
290 | |
291 @smallexample | |
292 -: 0:Source:tmp.c | |
293 -: 0:Graph:tmp.gcno | |
294 -: 0:Data:tmp.gcda | |
295 -: 0:Runs:1 | |
296 -: 0:Programs:1 | |
297 -: 1:#include <stdio.h> | |
298 -: 2: | |
299 -: 3:int main (void) | |
300 1: 4:@{ | |
301 1: 5: int i, total; | |
302 -: 6: | |
303 1: 7: total = 0; | |
304 -: 8: | |
305 11: 9: for (i = 0; i < 10; i++) | |
306 10: 10: total += i; | |
307 -: 11: | |
308 1: 12: if (total != 45) | |
309 #####: 13: printf ("Failure\n"); | |
310 -: 14: else | |
311 1: 15: printf ("Success\n"); | |
312 1: 16: return 0; | |
313 -: 17:@} | |
314 @end smallexample | |
315 | |
316 When you use the @option{-a} option, you will get individual block | |
317 counts, and the output looks like this: | |
318 | |
319 @smallexample | |
320 -: 0:Source:tmp.c | |
321 -: 0:Graph:tmp.gcno | |
322 -: 0:Data:tmp.gcda | |
323 -: 0:Runs:1 | |
324 -: 0:Programs:1 | |
325 -: 1:#include <stdio.h> | |
326 -: 2: | |
327 -: 3:int main (void) | |
328 1: 4:@{ | |
329 1: 4-block 0 | |
330 1: 5: int i, total; | |
331 -: 6: | |
332 1: 7: total = 0; | |
333 -: 8: | |
334 11: 9: for (i = 0; i < 10; i++) | |
335 11: 9-block 0 | |
336 10: 10: total += i; | |
337 10: 10-block 0 | |
338 -: 11: | |
339 1: 12: if (total != 45) | |
340 1: 12-block 0 | |
341 #####: 13: printf ("Failure\n"); | |
342 $$$$$: 13-block 0 | |
343 -: 14: else | |
344 1: 15: printf ("Success\n"); | |
345 1: 15-block 0 | |
346 1: 16: return 0; | |
347 1: 16-block 0 | |
348 -: 17:@} | |
349 @end smallexample | |
350 | |
351 In this mode, each basic block is only shown on one line -- the last | |
352 line of the block. A multi-line block will only contribute to the | |
353 execution count of that last line, and other lines will not be shown | |
354 to contain code, unless previous blocks end on those lines. | |
355 The total execution count of a line is shown and subsequent lines show | |
356 the execution counts for individual blocks that end on that line. After each | |
357 block, the branch and call counts of the block will be shown, if the | |
358 @option{-b} option is given. | |
359 | |
360 Because of the way GCC instruments calls, a call count can be shown | |
361 after a line with no individual blocks. | |
362 As you can see, line 13 contains a basic block that was not executed. | |
363 | |
364 @need 450 | |
365 When you use the @option{-b} option, your output looks like this: | |
366 | |
367 @smallexample | |
368 $ gcov -b tmp.c | |
369 90.00% of 10 source lines executed in file tmp.c | |
370 80.00% of 5 branches executed in file tmp.c | |
371 80.00% of 5 branches taken at least once in file tmp.c | |
372 50.00% of 2 calls executed in file tmp.c | |
373 Creating tmp.c.gcov. | |
374 @end smallexample | |
375 | |
376 Here is a sample of a resulting @file{tmp.c.gcov} file: | |
377 | |
378 @smallexample | |
379 -: 0:Source:tmp.c | |
380 -: 0:Graph:tmp.gcno | |
381 -: 0:Data:tmp.gcda | |
382 -: 0:Runs:1 | |
383 -: 0:Programs:1 | |
384 -: 1:#include <stdio.h> | |
385 -: 2: | |
386 -: 3:int main (void) | |
387 function main called 1 returned 1 blocks executed 75% | |
388 1: 4:@{ | |
389 1: 5: int i, total; | |
390 -: 6: | |
391 1: 7: total = 0; | |
392 -: 8: | |
393 11: 9: for (i = 0; i < 10; i++) | |
394 branch 0 taken 91% (fallthrough) | |
395 branch 1 taken 9% | |
396 10: 10: total += i; | |
397 -: 11: | |
398 1: 12: if (total != 45) | |
399 branch 0 taken 0% (fallthrough) | |
400 branch 1 taken 100% | |
401 #####: 13: printf ("Failure\n"); | |
402 call 0 never executed | |
403 -: 14: else | |
404 1: 15: printf ("Success\n"); | |
405 call 0 called 1 returned 100% | |
406 1: 16: return 0; | |
407 -: 17:@} | |
408 @end smallexample | |
409 | |
410 For each function, a line is printed showing how many times the function | |
411 is called, how many times it returns and what percentage of the | |
412 function's blocks were executed. | |
413 | |
414 For each basic block, a line is printed after the last line of the basic | |
415 block describing the branch or call that ends the basic block. There can | |
416 be multiple branches and calls listed for a single source line if there | |
417 are multiple basic blocks that end on that line. In this case, the | |
418 branches and calls are each given a number. There is no simple way to map | |
419 these branches and calls back to source constructs. In general, though, | |
420 the lowest numbered branch or call will correspond to the leftmost construct | |
421 on the source line. | |
422 | |
423 For a branch, if it was executed at least once, then a percentage | |
424 indicating the number of times the branch was taken divided by the | |
425 number of times the branch was executed will be printed. Otherwise, the | |
426 message ``never executed'' is printed. | |
427 | |
428 For a call, if it was executed at least once, then a percentage | |
429 indicating the number of times the call returned divided by the number | |
430 of times the call was executed will be printed. This will usually be | |
431 100%, but may be less for functions that call @code{exit} or @code{longjmp}, | |
432 and thus may not return every time they are called. | |
433 | |
434 The execution counts are cumulative. If the example program were | |
435 executed again without removing the @file{.gcda} file, the count for the | |
436 number of times each line in the source was executed would be added to | |
437 the results of the previous run(s). This is potentially useful in | |
438 several ways. For example, it could be used to accumulate data over a | |
439 number of program runs as part of a test verification suite, or to | |
440 provide more accurate long-term information over a large number of | |
441 program runs. | |
442 | |
443 The data in the @file{.gcda} files is saved immediately before the program | |
444 exits. For each source file compiled with @option{-fprofile-arcs}, the | |
445 profiling code first attempts to read in an existing @file{.gcda} file; if | |
446 the file doesn't match the executable (differing number of basic block | |
447 counts) it will ignore the contents of the file. It then adds in the | |
448 new execution counts and finally writes the data to the file. | |
449 | |
450 @node Gcov and Optimization | |
451 @section Using @command{gcov} with GCC Optimization | |
452 | |
453 If you plan to use @command{gcov} to help optimize your code, you must | |
454 first compile your program with two special GCC options: | |
455 @samp{-fprofile-arcs -ftest-coverage}. Aside from that, you can use any | |
456 other GCC options; but if you want to prove that every single line | |
457 in your program was executed, you should not compile with optimization | |
458 at the same time. On some machines the optimizer can eliminate some | |
459 simple code lines by combining them with other lines. For example, code | |
460 like this: | |
461 | |
462 @smallexample | |
463 if (a != b) | |
464 c = 1; | |
465 else | |
466 c = 0; | |
467 @end smallexample | |
468 | |
469 @noindent | |
470 can be compiled into one instruction on some machines. In this case, | |
471 there is no way for @command{gcov} to calculate separate execution counts | |
472 for each line because there isn't separate code for each line. Hence | |
473 the @command{gcov} output looks like this if you compiled the program with | |
474 optimization: | |
475 | |
476 @smallexample | |
477 100: 12:if (a != b) | |
478 100: 13: c = 1; | |
479 100: 14:else | |
480 100: 15: c = 0; | |
481 @end smallexample | |
482 | |
483 The output shows that this block of code, combined by optimization, | |
484 executed 100 times. In one sense this result is correct, because there | |
485 was only one instruction representing all four of these lines. However, | |
486 the output does not indicate how many times the result was 0 and how | |
487 many times the result was 1. | |
488 | |
489 Inlineable functions can create unexpected line counts. Line counts are | |
490 shown for the source code of the inlineable function, but what is shown | |
491 depends on where the function is inlined, or if it is not inlined at all. | |
492 | |
493 If the function is not inlined, the compiler must emit an out of line | |
494 copy of the function, in any object file that needs it. If | |
495 @file{fileA.o} and @file{fileB.o} both contain out of line bodies of a | |
496 particular inlineable function, they will also both contain coverage | |
497 counts for that function. When @file{fileA.o} and @file{fileB.o} are | |
498 linked together, the linker will, on many systems, select one of those | |
499 out of line bodies for all calls to that function, and remove or ignore | |
500 the other. Unfortunately, it will not remove the coverage counters for | |
501 the unused function body. Hence when instrumented, all but one use of | |
502 that function will show zero counts. | |
503 | |
504 If the function is inlined in several places, the block structure in | |
505 each location might not be the same. For instance, a condition might | |
506 now be calculable at compile time in some instances. Because the | |
507 coverage of all the uses of the inline function will be shown for the | |
508 same source lines, the line counts themselves might seem inconsistent. | |
509 | |
510 @c man end | |
511 | |
512 @node Gcov Data Files | |
513 @section Brief description of @command{gcov} data files | |
514 | |
515 @command{gcov} uses two files for profiling. The names of these files | |
516 are derived from the original @emph{object} file by substituting the | |
517 file suffix with either @file{.gcno}, or @file{.gcda}. All of these files | |
518 are placed in the same directory as the object file, and contain data | |
519 stored in a platform-independent format. | |
520 | |
521 The @file{.gcno} file is generated when the source file is compiled with | |
522 the GCC @option{-ftest-coverage} option. It contains information to | |
523 reconstruct the basic block graphs and assign source line numbers to | |
524 blocks. | |
525 | |
526 The @file{.gcda} file is generated when a program containing object files | |
527 built with the GCC @option{-fprofile-arcs} option is executed. A | |
528 separate @file{.gcda} file is created for each object file compiled with | |
529 this option. It contains arc transition counts, and some summary | |
530 information. | |
531 | |
532 The full details of the file format is specified in @file{gcov-io.h}, | |
533 and functions provided in that header file should be used to access the | |
534 coverage files. | |
535 | |
536 @node Cross-profiling | |
537 @section Data file relocation to support cross-profiling | |
538 | |
539 Running the program will cause profile output to be generated. For each | |
540 source file compiled with @option{-fprofile-arcs}, an accompanying @file{.gcda} | |
541 file will be placed in the object file directory. That implicitly requires | |
542 running the program on the same system as it was built or having the same | |
543 absolute directory structure on the target system. The program will try | |
544 to create the needed directory structure, if it is not already present. | |
545 | |
546 To support cross-profiling, a program compiled with @option{-fprofile-arcs} | |
547 can relocate the data files based on two environment variables: | |
548 | |
549 @itemize @bullet | |
550 @item | |
551 GCOV_PREFIX contains the prefix to add to the absolute paths | |
552 in the object file. Prefix must be absolute as well, otherwise its | |
553 value is ignored. The default is no prefix. | |
554 | |
555 @item | |
556 GCOV_PREFIX_STRIP indicates the how many initial directory names to strip off | |
557 the hardwired absolute paths. Default value is 0. | |
558 | |
559 @emph{Note:} GCOV_PREFIX_STRIP has no effect if GCOV_PREFIX is undefined, empty | |
560 or non-absolute. | |
561 @end itemize | |
562 | |
563 For example, if the object file @file{/user/build/foo.o} was built with | |
564 @option{-fprofile-arcs}, the final executable will try to create the data file | |
565 @file{/user/build/foo.gcda} when running on the target system. This will | |
566 fail if the corresponding directory does not exist and it is unable to create | |
567 it. This can be overcome by, for example, setting the environment as | |
568 @samp{GCOV_PREFIX=/target/run} and @samp{GCOV_PREFIX_STRIP=1}. Such a | |
569 setting will name the data file @file{/target/run/build/foo.gcda}. | |
570 | |
571 You must move the data files to the expected directory tree in order to | |
572 use them for profile directed optimizations (@option{--use-profile}), or to | |
573 use the @command{gcov} tool. |