0
|
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.
|