]>
Commit | Line | Data |
---|---|---|
c63539ff ML |
1 | .. |
2 | Copyright 1988-2022 Free Software Foundation, Inc. | |
3 | This is part of the GCC manual. | |
4 | For copying conditions, see the copyright.rst file. | |
5 | ||
6 | .. _gcov-intro: | |
7 | ||
8 | Introduction to gcov | |
9 | ******************** | |
10 | ||
11 | :command:`gcov` is a test coverage program. Use it in concert with GCC | |
12 | to analyze your programs to help create more efficient, faster running | |
13 | code and to discover untested parts of your program. You can use | |
14 | :command:`gcov` as a profiling tool to help discover where your | |
15 | optimization efforts will best affect your code. You can also use | |
16 | :command:`gcov` along with the other profiling tool, :command:`gprof`, to | |
17 | assess which parts of your code use the greatest amount of computing | |
18 | time. | |
19 | ||
20 | Profiling tools help you analyze your code's performance. Using a | |
21 | profiler such as :command:`gcov` or :command:`gprof`, you can find out some | |
22 | basic performance statistics, such as: | |
23 | ||
24 | * how often each line of code executes | |
25 | ||
26 | * what lines of code are actually executed | |
27 | ||
28 | * how much computing time each section of code uses | |
29 | ||
30 | Once you know these things about how your code works when compiled, you | |
31 | can look at each module to see which modules should be optimized. | |
32 | :command:`gcov` helps you determine where to work on optimization. | |
33 | ||
34 | Software developers also use coverage testing in concert with | |
35 | testsuites, to make sure software is actually good enough for a release. | |
36 | Testsuites can verify that a program works as expected; a coverage | |
37 | program tests to see how much of the program is exercised by the | |
38 | testsuite. Developers can then determine what kinds of test cases need | |
39 | to be added to the testsuites to create both better testing and a better | |
40 | final product. | |
41 | ||
42 | You should compile your code without optimization if you plan to use | |
43 | :command:`gcov` because the optimization, by combining some lines of code | |
44 | into one function, may not give you as much information as you need to | |
45 | look for 'hot spots' where the code is using a great deal of computer | |
46 | time. Likewise, because :command:`gcov` accumulates statistics by line (at | |
47 | the lowest resolution), it works best with a programming style that | |
48 | places only one statement on each line. If you use complicated macros | |
49 | that expand to loops or to other control structures, the statistics are | |
50 | less helpful---they only report on the line where the macro call | |
51 | appears. If your complex macros behave like functions, you can replace | |
52 | them with inline functions to solve this problem. | |
53 | ||
54 | :command:`gcov` creates a logfile called :samp:`{sourcefile}.gcov` which | |
55 | indicates how many times each line of a source file :samp:`{sourcefile}.c` | |
56 | has executed. You can use these logfiles along with :command:`gprof` to aid | |
57 | in fine-tuning the performance of your programs. :command:`gprof` gives | |
58 | timing information you can use along with the information you get from | |
59 | :command:`gcov`. | |
60 | ||
61 | :command:`gcov` works only on code compiled with GCC. It is not | |
62 | compatible with any other profiling or test coverage mechanism. |