Import stripped Arm GNU Toolchain 13.2.Rel1HEADumineko

https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads

Change-Id: I7303388733328cd98ab9aa3c30236db67f2e9e9c

1 files changed, 1045 insertions, 0 deletions

diff --git a/share/man/man1/aarch64-none-linux-gnu-gcov.1 b/share/man/man1/aarch64-none-linux-gnu-gcov.1
new file mode 100644
index 0000000..831f121
--- /dev/null
+++ b/share/man/man1/aarch64-none-linux-gnu-gcov.1
@@ -0,0 +1,1045 @@
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings.  \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
+.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+.    ds -- \(*W-
+.    ds PI pi
+.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
+.    ds L" ""
+.    ds R" ""
+.    ds C` ""
+.    ds C' ""
+'br\}
+.el\{\
+.    ds -- \|\(em\|
+.    ds PI \(*p
+.    ds L" ``
+.    ds R" ''
+.    ds C`
+.    ds C'
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el       .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD.  Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
+..
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
+..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
+.\}
+.rr rF
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear.  Run.  Save yourself.  No user-serviceable parts.
+.    \" fudge factors for nroff and troff
+.if n \{\
+.    ds #H 0
+.    ds #V .8m
+.    ds #F .3m
+.    ds #[ \f1
+.    ds #] \fP
+.\}
+.if t \{\
+.    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+.    ds #V .6m
+.    ds #F 0
+.    ds #[ \&
+.    ds #] \&
+.\}
+.    \" simple accents for nroff and troff
+.if n \{\
+.    ds ' \&
+.    ds ` \&
+.    ds ^ \&
+.    ds , \&
+.    ds ~ ~
+.    ds /
+.\}
+.if t \{\
+.    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+.    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+.    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+.    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+.    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+.    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+.    \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+.    \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+.    \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+.    ds : e
+.    ds 8 ss
+.    ds o a
+.    ds d- d\h'-1'\(ga
+.    ds D- D\h'-1'\(hy
+.    ds th \o'bp'
+.    ds Th \o'LP'
+.    ds ae ae
+.    ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "GCOV 1"
+.TH GCOV 1 "2023-10-09" "gcc-13.2.1" "GNU"
+.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+gcov \- coverage testing tool
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+gcov [\fB\-v\fR|\fB\-\-version\fR] [\fB\-h\fR|\fB\-\-help\fR]
+     [\fB\-a\fR|\fB\-\-all\-blocks\fR]
+     [\fB\-b\fR|\fB\-\-branch\-probabilities\fR]
+     [\fB\-c\fR|\fB\-\-branch\-counts\fR]
+     [\fB\-d\fR|\fB\-\-display\-progress\fR]
+     [\fB\-f\fR|\fB\-\-function\-summaries\fR]
+     [\fB\-j\fR|\fB\-\-json\-format\fR]
+     [\fB\-H\fR|\fB\-\-human\-readable\fR]
+     [\fB\-k\fR|\fB\-\-use\-colors\fR]
+     [\fB\-l\fR|\fB\-\-long\-file\-names\fR]
+     [\fB\-m\fR|\fB\-\-demangled\-names\fR]
+     [\fB\-n\fR|\fB\-\-no\-output\fR]
+     [\fB\-o\fR|\fB\-\-object\-directory\fR \fIdirectory|file\fR]
+     [\fB\-p\fR|\fB\-\-preserve\-paths\fR]
+     [\fB\-q\fR|\fB\-\-use\-hotness\-colors\fR]
+     [\fB\-r\fR|\fB\-\-relative\-only\fR]
+     [\fB\-s\fR|\fB\-\-source\-prefix\fR \fIdirectory\fR]
+     [\fB\-t\fR|\fB\-\-stdout\fR]
+     [\fB\-u\fR|\fB\-\-unconditional\-branches\fR]
+     [\fB\-x\fR|\fB\-\-hash\-filenames\fR]
+     \fIfiles\fR
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+\&\fBgcov\fR is a test coverage program.  Use it in concert with \s-1GCC\s0
+to analyze your programs to help create more efficient, faster running
+code and to discover untested parts of your program.  You can use
+\&\fBgcov\fR as a profiling tool to help discover where your
+optimization efforts will best affect your code.  You can also use
+\&\fBgcov\fR along with the other profiling tool, \fBgprof\fR, to
+assess which parts of your code use the greatest amount of computing
+time.
+.PP
+Profiling tools help you analyze your code's performance.  Using a
+profiler such as \fBgcov\fR or \fBgprof\fR, you can find out some
+basic performance statistics, such as:
+.IP "*" 4
+how often each line of code executes
+.IP "*" 4
+what lines of code are actually executed
+.IP "*" 4
+how much computing time each section of code uses
+.PP
+Once you know these things about how your code works when compiled, you
+can look at each module to see which modules should be optimized.
+\&\fBgcov\fR helps you determine where to work on optimization.
+.PP
+Software developers also use coverage testing in concert with
+testsuites, to make sure software is actually good enough for a release.
+Testsuites can verify that a program works as expected; a coverage
+program tests to see how much of the program is exercised by the
+testsuite.  Developers can then determine what kinds of test cases need
+to be added to the testsuites to create both better testing and a better
+final product.
+.PP
+You should compile your code without optimization if you plan to use
+\&\fBgcov\fR because the optimization, by combining some lines of code
+into one function, may not give you as much information as you need to
+look for `hot spots' where the code is using a great deal of computer
+time.  Likewise, because \fBgcov\fR accumulates statistics by line (at
+the lowest resolution), it works best with a programming style that
+places only one statement on each line.  If you use complicated macros
+that expand to loops or to other control structures, the statistics are
+less helpful\-\-\-they only report on the line where the macro call
+appears.  If your complex macros behave like functions, you can replace
+them with inline functions to solve this problem.
+.PP
+\&\fBgcov\fR creates a logfile called \fI\fIsourcefile\fI.gcov\fR which
+indicates how many times each line of a source file \fI\fIsourcefile\fI.c\fR
+has executed.  You can use these logfiles along with \fBgprof\fR to aid
+in fine-tuning the performance of your programs.  \fBgprof\fR gives
+timing information you can use along with the information you get from
+\&\fBgcov\fR.
+.PP
+\&\fBgcov\fR works only on code compiled with \s-1GCC. \s0 It is not
+compatible with any other profiling or test coverage mechanism.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.IP "\fB\-a\fR" 4
+.IX Item "-a"
+.PD 0
+.IP "\fB\-\-all\-blocks\fR" 4
+.IX Item "--all-blocks"
+.PD
+Write individual execution counts for every basic block.  Normally gcov
+outputs execution counts only for the main blocks of a line.  With this
+option you can determine if blocks within a single line are not being
+executed.
+.IP "\fB\-b\fR" 4
+.IX Item "-b"
+.PD 0
+.IP "\fB\-\-branch\-probabilities\fR" 4
+.IX Item "--branch-probabilities"
+.PD
+Write branch frequencies to the output file, and write branch summary
+info to the standard output.  This option allows you to see how often
+each branch in your program was taken.  Unconditional branches will not
+be shown, unless the \fB\-u\fR option is given.
+.IP "\fB\-c\fR" 4
+.IX Item "-c"
+.PD 0
+.IP "\fB\-\-branch\-counts\fR" 4
+.IX Item "--branch-counts"
+.PD
+Write branch frequencies as the number of branches taken, rather than
+the percentage of branches taken.
+.IP "\fB\-d\fR" 4
+.IX Item "-d"
+.PD 0
+.IP "\fB\-\-display\-progress\fR" 4
+.IX Item "--display-progress"
+.PD
+Display the progress on the standard output.
+.IP "\fB\-f\fR" 4
+.IX Item "-f"
+.PD 0
+.IP "\fB\-\-function\-summaries\fR" 4
+.IX Item "--function-summaries"
+.PD
+Output summaries for each function in addition to the file level summary.
+.IP "\fB\-h\fR" 4
+.IX Item "-h"
+.PD 0
+.IP "\fB\-\-help\fR" 4
+.IX Item "--help"
+.PD
+Display help about using \fBgcov\fR (on the standard output), and
+exit without doing any further processing.
+.IP "\fB\-j\fR" 4
+.IX Item "-j"
+.PD 0
+.IP "\fB\-\-json\-format\fR" 4
+.IX Item "--json-format"
+.PD
+Output gcov file in an easy-to-parse \s-1JSON\s0 intermediate format
+which does not require source code for generation.  The \s-1JSON\s0
+file is compressed with gzip compression algorithm
+and the files have \fI.gcov.json.gz\fR extension.
+.Sp
+Structure of the \s-1JSON\s0 is following:
+.Sp
+.Vb 7
+\&        {
+\&          "current_working_directory": "foo/bar",
+\&          "data_file": "a.out",
+\&          "format_version": "1",
+\&          "gcc_version": "11.1.1 20210510"
+\&          "files": ["$file"]
+\&        }
+.Ve
+.Sp
+Fields of the root element have following semantics:
+.RS 4
+.IP "*" 4
+\&\fIcurrent_working_directory\fR: working directory where
+a compilation unit was compiled
+.IP "*" 4
+\&\fIdata_file\fR: name of the data file (\s-1GCDA\s0)
+.IP "*" 4
+\&\fIformat_version\fR: semantic version of the format
+.IP "*" 4
+\&\fIgcc_version\fR: version of the \s-1GCC\s0 compiler
+.RE
+.RS 4
+.Sp
+Each \fIfile\fR has the following form:
+.Sp
+.Vb 5
+\&        {
+\&          "file": "a.c",
+\&          "functions": ["$function"],
+\&          "lines": ["$line"]
+\&        }
+.Ve
+.Sp
+Fields of the \fIfile\fR element have following semantics:
+.IP "*" 4
+\&\fIfile_name\fR: name of the source file
+.RE
+.RS 4
+.Sp
+Each \fIfunction\fR has the following form:
+.Sp
+.Vb 11
+\&        {
+\&          "blocks": 2,
+\&          "blocks_executed": 2,
+\&          "demangled_name": "foo",
+\&          "end_column": 1,
+\&          "end_line": 4,
+\&          "execution_count": 1,
+\&          "name": "foo",
+\&          "start_column": 5,
+\&          "start_line": 1
+\&        }
+.Ve
+.Sp
+Fields of the \fIfunction\fR element have following semantics:
+.IP "*" 4
+\&\fIblocks\fR: number of blocks that are in the function
+.IP "*" 4
+\&\fIblocks_executed\fR: number of executed blocks of the function
+.IP "*" 4
+\&\fIdemangled_name\fR: demangled name of the function
+.IP "*" 4
+\&\fIend_column\fR: column in the source file where the function ends
+.IP "*" 4
+\&\fIend_line\fR: line in the source file where the function ends
+.IP "*" 4
+\&\fIexecution_count\fR: number of executions of the function
+.IP "*" 4
+\&\fIname\fR: name of the function
+.IP "*" 4
+\&\fIstart_column\fR: column in the source file where the function begins
+.IP "*" 4
+\&\fIstart_line\fR: line in the source file where the function begins
+.RE
+.RS 4
+.Sp
+Note that line numbers and column numbers number from 1.  In the current
+implementation, \fIstart_line\fR and \fIstart_column\fR do not include
+any template parameters and the leading return type but that
+this is likely to be fixed in the future.
+.Sp
+Each \fIline\fR has the following form:
+.Sp
+.Vb 7
+\&        {
+\&          "branches": ["$branch"],
+\&          "count": 2,
+\&          "line_number": 15,
+\&          "unexecuted_block": false,
+\&          "function_name": "foo",
+\&        }
+.Ve
+.Sp
+Branches are present only with \fI\-b\fR option.
+Fields of the \fIline\fR element have following semantics:
+.IP "*" 4
+\&\fIcount\fR: number of executions of the line
+.IP "*" 4
+\&\fIline_number\fR: line number
+.IP "*" 4
+\&\fIunexecuted_block\fR: flag whether the line contains an unexecuted block
+(not all statements on the line are executed)
+.IP "*" 4
+\&\fIfunction_name\fR: a name of a function this \fIline\fR belongs to
+(for a line with an inlined statements can be not set)
+.RE
+.RS 4
+.Sp
+Each \fIbranch\fR has the following form:
+.Sp
+.Vb 5
+\&        {
+\&          "count": 11,
+\&          "fallthrough": true,
+\&          "throw": false
+\&        }
+.Ve
+.Sp
+Fields of the \fIbranch\fR element have following semantics:
+.IP "*" 4
+\&\fIcount\fR: number of executions of the branch
+.IP "*" 4
+\&\fIfallthrough\fR: true when the branch is a fall through branch
+.IP "*" 4
+\&\fIthrow\fR: true when the branch is an exceptional branch
+.RE
+.RS 4
+.RE
+.IP "\fB\-H\fR" 4
+.IX Item "-H"
+.PD 0
+.IP "\fB\-\-human\-readable\fR" 4
+.IX Item "--human-readable"
+.PD
+Write counts in human readable format (like 24.6k).
+.IP "\fB\-k\fR" 4
+.IX Item "-k"
+.PD 0
+.IP "\fB\-\-use\-colors\fR" 4
+.IX Item "--use-colors"
+.PD
+Use colors for lines of code that have zero coverage.  We use red color for
+non-exceptional lines and cyan for exceptional.  Same colors are used for
+basic blocks with \fB\-a\fR option.
+.IP "\fB\-l\fR" 4
+.IX Item "-l"
+.PD 0
+.IP "\fB\-\-long\-file\-names\fR" 4
+.IX Item "--long-file-names"
+.PD
+Create long file names for included source files.  For example, if the
+header file \fIx.h\fR contains code, and was included in the file
+\&\fIa.c\fR, then running \fBgcov\fR on the file \fIa.c\fR will
+produce an output file called \fIa.c##x.h.gcov\fR instead of
+\&\fIx.h.gcov\fR.  This can be useful if \fIx.h\fR is included in
+multiple source files and you want to see the individual
+contributions.  If you use the \fB\-p\fR option, both the including
+and included file names will be complete path names.
+.IP "\fB\-m\fR" 4
+.IX Item "-m"
+.PD 0
+.IP "\fB\-\-demangled\-names\fR" 4
+.IX Item "--demangled-names"
+.PD
+Display demangled function names in output. The default is to show
+mangled function names.
+.IP "\fB\-n\fR" 4
+.IX Item "-n"
+.PD 0
+.IP "\fB\-\-no\-output\fR" 4
+.IX Item "--no-output"
+.PD
+Do not create the \fBgcov\fR output file.
+.IP "\fB\-o\fR \fIdirectory|file\fR" 4
+.IX Item "-o directory|file"
+.PD 0
+.IP "\fB\-\-object\-directory\fR \fIdirectory\fR" 4
+.IX Item "--object-directory directory"
+.IP "\fB\-\-object\-file\fR \fIfile\fR" 4
+.IX Item "--object-file file"
+.PD
+Specify either the directory containing the gcov data files, or the
+object path name.  The \fI.gcno\fR, and
+\&\fI.gcda\fR data files are searched for using this option.  If a directory
+is specified, the data files are in that directory and named after the
+input file name, without its extension.  If a file is specified here,
+the data files are named after that file, without its extension.
+.IP "\fB\-p\fR" 4
+.IX Item "-p"
+.PD 0
+.IP "\fB\-\-preserve\-paths\fR" 4
+.IX Item "--preserve-paths"
+.PD
+Preserve complete path information in the names of generated
+\&\fI.gcov\fR files.  Without this option, just the filename component is
+used.  With this option, all directories are used, with \fB/\fR characters
+translated to \fB#\fR characters, \fI.\fR directory components
+removed and unremoveable \fI..\fR
+components renamed to \fB^\fR.  This is useful if sourcefiles are in several
+different directories.
+.IP "\fB\-q\fR" 4
+.IX Item "-q"
+.PD 0
+.IP "\fB\-\-use\-hotness\-colors\fR" 4
+.IX Item "--use-hotness-colors"
+.PD
+Emit perf-like colored output for hot lines.  Legend of the color scale
+is printed at the very beginning of the output file.
+.IP "\fB\-r\fR" 4
+.IX Item "-r"
+.PD 0
+.IP "\fB\-\-relative\-only\fR" 4
+.IX Item "--relative-only"
+.PD
+Only output information about source files with a relative pathname
+(after source prefix elision).  Absolute paths are usually system
+header files and coverage of any inline functions therein is normally
+uninteresting.
+.IP "\fB\-s\fR \fIdirectory\fR" 4
+.IX Item "-s directory"
+.PD 0
+.IP "\fB\-\-source\-prefix\fR \fIdirectory\fR" 4
+.IX Item "--source-prefix directory"
+.PD
+A prefix for source file names to remove when generating the output
+coverage files.  This option is useful when building in a separate
+directory, and the pathname to the source directory is not wanted when
+determining the output file names.  Note that this prefix detection is
+applied before determining whether the source file is absolute.
+.IP "\fB\-t\fR" 4
+.IX Item "-t"
+.PD 0
+.IP "\fB\-\-stdout\fR" 4
+.IX Item "--stdout"
+.PD
+Output to standard output instead of output files.
+.IP "\fB\-u\fR" 4
+.IX Item "-u"
+.PD 0
+.IP "\fB\-\-unconditional\-branches\fR" 4
+.IX Item "--unconditional-branches"
+.PD
+When branch probabilities are given, include those of unconditional branches.
+Unconditional branches are normally not interesting.
+.IP "\fB\-v\fR" 4
+.IX Item "-v"
+.PD 0
+.IP "\fB\-\-version\fR" 4
+.IX Item "--version"
+.PD
+Display the \fBgcov\fR version number (on the standard output),
+and exit without doing any further processing.
+.IP "\fB\-w\fR" 4
+.IX Item "-w"
+.PD 0
+.IP "\fB\-\-verbose\fR" 4
+.IX Item "--verbose"
+.PD
+Print verbose informations related to basic blocks and arcs.
+.IP "\fB\-x\fR" 4
+.IX Item "-x"
+.PD 0
+.IP "\fB\-\-hash\-filenames\fR" 4
+.IX Item "--hash-filenames"
+.PD
+When using \fI\-\-preserve\-paths\fR,
+gcov uses the full pathname of the source files to create
+an output filename.  This can lead to long filenames that can overflow
+filesystem limits.  This option creates names of the form
+\&\fI\fIsource-file\fI##\fImd5\fI.gcov\fR,
+where the \fIsource-file\fR component is the final filename part and
+the \fImd5\fR component is calculated from the full mangled name that
+would have been used otherwise.  The option is an alternative
+to the \fI\-\-preserve\-paths\fR on systems which have a filesystem limit.
+.PP
+\&\fBgcov\fR should be run with the current directory the same as that
+when you invoked the compiler.  Otherwise it will not be able to locate
+the source files.  \fBgcov\fR produces files called
+\&\fI\fImangledname\fI.gcov\fR in the current directory.  These contain
+the coverage information of the source file they correspond to.
+One \fI.gcov\fR file is produced for each source (or header) file
+containing code,
+which was compiled to produce the data files.  The \fImangledname\fR part
+of the output file name is usually simply the source file name, but can
+be something more complicated if the \fB\-l\fR or \fB\-p\fR options are
+given.  Refer to those options for details.
+.PP
+If you invoke \fBgcov\fR with multiple input files, the
+contributions from each input file are summed.  Typically you would
+invoke it with the same list of files as the final link of your executable.
+.PP
+The \fI.gcov\fR files contain the \fB:\fR separated fields along with
+program source code.  The format is
+.PP
+.Vb 1
+\&        <execution_count>:<line_number>:<source line text>
+.Ve
+.PP
+Additional block information may succeed each line, when requested by
+command line option.  The \fIexecution_count\fR is \fB\-\fR for lines
+containing no code.  Unexecuted lines are marked \fB#####\fR or
+\&\fB=====\fR, depending on whether they are reachable by
+non-exceptional paths or only exceptional paths such as \*(C+ exception
+handlers, respectively. Given the \fB\-a\fR option, unexecuted blocks are
+marked \fB$$$$$\fR or \fB%%%%%\fR, depending on whether a basic block
+is reachable via non-exceptional or exceptional paths.
+Executed basic blocks having a statement with zero \fIexecution_count\fR
+end with \fB*\fR character and are colored with magenta color with
+the \fB\-k\fR option.  This functionality is not supported in Ada.
+.PP
+Note that \s-1GCC\s0 can completely remove the bodies of functions that are
+not needed \*(-- for instance if they are inlined everywhere.  Such functions
+are marked with \fB\-\fR, which can be confusing.
+Use the \fB\-fkeep\-inline\-functions\fR and \fB\-fkeep\-static\-functions\fR
+options to retain these functions and
+allow gcov to properly show their \fIexecution_count\fR.
+.PP
+Some lines of information at the start have \fIline_number\fR of zero.
+These preamble lines are of the form
+.PP
+.Vb 1
+\&        \-:0:<tag>:<value>
+.Ve
+.PP
+The ordering and number of these preamble lines will be augmented as
+\&\fBgcov\fR development progresses \-\-\- do not rely on them remaining
+unchanged.  Use \fItag\fR to locate a particular preamble line.
+.PP
+The additional block information is of the form
+.PP
+.Vb 1
+\&        <tag> <information>
+.Ve
+.PP
+The \fIinformation\fR is human readable, but designed to be simple
+enough for machine parsing too.
+.PP
+When printing percentages, 0% and 100% are only printed when the values
+are \fIexactly\fR 0% and 100% respectively.  Other values which would
+conventionally be rounded to 0% or 100% are instead printed as the
+nearest non-boundary value.
+.PP
+When using \fBgcov\fR, you must first compile your program
+with a special \s-1GCC\s0 option \fB\-\-coverage\fR.
+This tells the compiler to generate additional information needed by
+gcov (basically a flow graph of the program) and also includes
+additional code in the object files for generating the extra profiling
+information needed by gcov.  These additional files are placed in the
+directory where the object file is located.
+.PP
+Running the program will cause profile output to be generated.  For each
+source file compiled with \fB\-fprofile\-arcs\fR, an accompanying
+\&\fI.gcda\fR file will be placed in the object file directory.
+.PP
+Running \fBgcov\fR with your program's source file names as arguments
+will now produce a listing of the code along with frequency of execution
+for each line.  For example, if your program is called \fItmp.cpp\fR, this
+is what you see when you use the basic \fBgcov\fR facility:
+.PP
+.Vb 7
+\&        $ g++ \-\-coverage tmp.cpp \-c
+\&        $ g++ \-\-coverage tmp.o
+\&        $ a.out
+\&        $ gcov tmp.cpp \-m
+\&        File \*(Aqtmp.cpp\*(Aq
+\&        Lines executed:92.86% of 14
+\&        Creating \*(Aqtmp.cpp.gcov\*(Aq
+.Ve
+.PP
+The file \fItmp.cpp.gcov\fR contains output from \fBgcov\fR.
+Here is a sample:
+.PP
+.Vb 10
+\&                \-:    0:Source:tmp.cpp
+\&                \-:    0:Working directory:/home/gcc/testcase
+\&                \-:    0:Graph:tmp.gcno
+\&                \-:    0:Data:tmp.gcda
+\&                \-:    0:Runs:1
+\&                \-:    0:Programs:1
+\&                \-:    1:#include <stdio.h>
+\&                \-:    2:
+\&                \-:    3:template<class T>
+\&                \-:    4:class Foo
+\&                \-:    5:{
+\&                \-:    6:  public:
+\&               1*:    7:  Foo(): b (1000) {}
+\&        \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
+\&        Foo<char>::Foo():
+\&            #####:    7:  Foo(): b (1000) {}
+\&        \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
+\&        Foo<int>::Foo():
+\&                1:    7:  Foo(): b (1000) {}
+\&        \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
+\&               2*:    8:  void inc () { b++; }
+\&        \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
+\&        Foo<char>::inc():
+\&            #####:    8:  void inc () { b++; }
+\&        \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
+\&        Foo<int>::inc():
+\&                2:    8:  void inc () { b++; }
+\&        \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
+\&                \-:    9:
+\&                \-:   10:  private:
+\&                \-:   11:  int b;
+\&                \-:   12:};
+\&                \-:   13:
+\&                \-:   14:template class Foo<int>;
+\&                \-:   15:template class Foo<char>;
+\&                \-:   16:
+\&                \-:   17:int
+\&                1:   18:main (void)
+\&                \-:   19:{
+\&                \-:   20:  int i, total;
+\&                1:   21:  Foo<int> counter;
+\&                \-:   22:
+\&                1:   23:  counter.inc();
+\&                1:   24:  counter.inc();
+\&                1:   25:  total = 0;
+\&                \-:   26:
+\&               11:   27:  for (i = 0; i < 10; i++)
+\&               10:   28:    total += i;
+\&                \-:   29:
+\&               1*:   30:  int v = total > 100 ? 1 : 2;
+\&                \-:   31:
+\&                1:   32:  if (total != 45)
+\&            #####:   33:    printf ("Failure\en");
+\&                \-:   34:  else
+\&                1:   35:    printf ("Success\en");
+\&                1:   36:  return 0;
+\&                \-:   37:}
+.Ve
+.PP
+Note that line 7 is shown in the report multiple times.  First occurrence
+presents total number of execution of the line and the next two belong
+to instances of class Foo constructors.  As you can also see, line 30 contains
+some unexecuted basic blocks and thus execution count has asterisk symbol.
+.PP
+When you use the \fB\-a\fR option, you will get individual block
+counts, and the output looks like this:
+.PP
+.Vb 10
+\&                \-:    0:Source:tmp.cpp
+\&                \-:    0:Working directory:/home/gcc/testcase
+\&                \-:    0:Graph:tmp.gcno
+\&                \-:    0:Data:tmp.gcda
+\&                \-:    0:Runs:1
+\&                \-:    0:Programs:1
+\&                \-:    1:#include <stdio.h>
+\&                \-:    2:
+\&                \-:    3:template<class T>
+\&                \-:    4:class Foo
+\&                \-:    5:{
+\&                \-:    6:  public:
+\&               1*:    7:  Foo(): b (1000) {}
+\&        \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
+\&        Foo<char>::Foo():
+\&            #####:    7:  Foo(): b (1000) {}
+\&        \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
+\&        Foo<int>::Foo():
+\&                1:    7:  Foo(): b (1000) {}
+\&        \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
+\&               2*:    8:  void inc () { b++; }
+\&        \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
+\&        Foo<char>::inc():
+\&            #####:    8:  void inc () { b++; }
+\&        \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
+\&        Foo<int>::inc():
+\&                2:    8:  void inc () { b++; }
+\&        \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
+\&                \-:    9:
+\&                \-:   10:  private:
+\&                \-:   11:  int b;
+\&                \-:   12:};
+\&                \-:   13:
+\&                \-:   14:template class Foo<int>;
+\&                \-:   15:template class Foo<char>;
+\&                \-:   16:
+\&                \-:   17:int
+\&                1:   18:main (void)
+\&                \-:   19:{
+\&                \-:   20:  int i, total;
+\&                1:   21:  Foo<int> counter;
+\&                1:   21\-block  0
+\&                \-:   22:
+\&                1:   23:  counter.inc();
+\&                1:   23\-block  0
+\&                1:   24:  counter.inc();
+\&                1:   24\-block  0
+\&                1:   25:  total = 0;
+\&                \-:   26:
+\&               11:   27:  for (i = 0; i < 10; i++)
+\&                1:   27\-block  0
+\&               11:   27\-block  1
+\&               10:   28:    total += i;
+\&               10:   28\-block  0
+\&                \-:   29:
+\&               1*:   30:  int v = total > 100 ? 1 : 2;
+\&                1:   30\-block  0
+\&            %%%%%:   30\-block  1
+\&                1:   30\-block  2
+\&                \-:   31:
+\&                1:   32:  if (total != 45)
+\&                1:   32\-block  0
+\&            #####:   33:    printf ("Failure\en");
+\&            %%%%%:   33\-block  0
+\&                \-:   34:  else
+\&                1:   35:    printf ("Success\en");
+\&                1:   35\-block  0
+\&                1:   36:  return 0;
+\&                1:   36\-block  0
+\&                \-:   37:}
+.Ve
+.PP
+In this mode, each basic block is only shown on one line \*(-- the last
+line of the block.  A multi-line block will only contribute to the
+execution count of that last line, and other lines will not be shown
+to contain code, unless previous blocks end on those lines.
+The total execution count of a line is shown and subsequent lines show
+the execution counts for individual blocks that end on that line.  After each
+block, the branch and call counts of the block will be shown, if the
+\&\fB\-b\fR option is given.
+.PP
+Because of the way \s-1GCC\s0 instruments calls, a call count can be shown
+after a line with no individual blocks.
+As you can see, line 33 contains a basic block that was not executed.
+.PP
+When you use the \fB\-b\fR option, your output looks like this:
+.PP
+.Vb 10
+\&                \-:    0:Source:tmp.cpp
+\&                \-:    0:Working directory:/home/gcc/testcase
+\&                \-:    0:Graph:tmp.gcno
+\&                \-:    0:Data:tmp.gcda
+\&                \-:    0:Runs:1
+\&                \-:    0:Programs:1
+\&                \-:    1:#include <stdio.h>
+\&                \-:    2:
+\&                \-:    3:template<class T>
+\&                \-:    4:class Foo
+\&                \-:    5:{
+\&                \-:    6:  public:
+\&               1*:    7:  Foo(): b (1000) {}
+\&        \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
+\&        Foo<char>::Foo():
+\&        function Foo<char>::Foo() called 0 returned 0% blocks executed 0%
+\&            #####:    7:  Foo(): b (1000) {}
+\&        \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
+\&        Foo<int>::Foo():
+\&        function Foo<int>::Foo() called 1 returned 100% blocks executed 100%
+\&                1:    7:  Foo(): b (1000) {}
+\&        \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
+\&               2*:    8:  void inc () { b++; }
+\&        \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
+\&        Foo<char>::inc():
+\&        function Foo<char>::inc() called 0 returned 0% blocks executed 0%
+\&            #####:    8:  void inc () { b++; }
+\&        \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
+\&        Foo<int>::inc():
+\&        function Foo<int>::inc() called 2 returned 100% blocks executed 100%
+\&                2:    8:  void inc () { b++; }
+\&        \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
+\&                \-:    9:
+\&                \-:   10:  private:
+\&                \-:   11:  int b;
+\&                \-:   12:};
+\&                \-:   13:
+\&                \-:   14:template class Foo<int>;
+\&                \-:   15:template class Foo<char>;
+\&                \-:   16:
+\&                \-:   17:int
+\&        function main called 1 returned 100% blocks executed 81%
+\&                1:   18:main (void)
+\&                \-:   19:{
+\&                \-:   20:  int i, total;
+\&                1:   21:  Foo<int> counter;
+\&        call    0 returned 100%
+\&        branch  1 taken 100% (fallthrough)
+\&        branch  2 taken 0% (throw)
+\&                \-:   22:
+\&                1:   23:  counter.inc();
+\&        call    0 returned 100%
+\&        branch  1 taken 100% (fallthrough)
+\&        branch  2 taken 0% (throw)
+\&                1:   24:  counter.inc();
+\&        call    0 returned 100%
+\&        branch  1 taken 100% (fallthrough)
+\&        branch  2 taken 0% (throw)
+\&                1:   25:  total = 0;
+\&                \-:   26:
+\&               11:   27:  for (i = 0; i < 10; i++)
+\&        branch  0 taken 91% (fallthrough)
+\&        branch  1 taken 9%
+\&               10:   28:    total += i;
+\&                \-:   29:
+\&               1*:   30:  int v = total > 100 ? 1 : 2;
+\&        branch  0 taken 0% (fallthrough)
+\&        branch  1 taken 100%
+\&                \-:   31:
+\&                1:   32:  if (total != 45)
+\&        branch  0 taken 0% (fallthrough)
+\&        branch  1 taken 100%
+\&            #####:   33:    printf ("Failure\en");
+\&        call    0 never executed
+\&        branch  1 never executed
+\&        branch  2 never executed
+\&                \-:   34:  else
+\&                1:   35:    printf ("Success\en");
+\&        call    0 returned 100%
+\&        branch  1 taken 100% (fallthrough)
+\&        branch  2 taken 0% (throw)
+\&                1:   36:  return 0;
+\&                \-:   37:}
+.Ve
+.PP
+For each function, a line is printed showing how many times the function
+is called, how many times it returns and what percentage of the
+function's blocks were executed.
+.PP
+For each basic block, a line is printed after the last line of the basic
+block describing the branch or call that ends the basic block.  There can
+be multiple branches and calls listed for a single source line if there
+are multiple basic blocks that end on that line.  In this case, the
+branches and calls are each given a number.  There is no simple way to map
+these branches and calls back to source constructs.  In general, though,
+the lowest numbered branch or call will correspond to the leftmost construct
+on the source line.
+.PP
+For a branch, if it was executed at least once, then a percentage
+indicating the number of times the branch was taken divided by the
+number of times the branch was executed will be printed.  Otherwise, the
+message \*(L"never executed\*(R" is printed.
+.PP
+For a call, if it was executed at least once, then a percentage
+indicating the number of times the call returned divided by the number
+of times the call was executed will be printed.  This will usually be
+100%, but may be less for functions that call \f(CW\*(C`exit\*(C'\fR or \f(CW\*(C`longjmp\*(C'\fR,
+and thus may not return every time they are called.
+.PP
+The execution counts are cumulative.  If the example program were
+executed again without removing the \fI.gcda\fR file, the count for the
+number of times each line in the source was executed would be added to
+the results of the previous run(s).  This is potentially useful in
+several ways.  For example, it could be used to accumulate data over a
+number of program runs as part of a test verification suite, or to
+provide more accurate long-term information over a large number of
+program runs.
+.PP
+The data in the \fI.gcda\fR files is saved immediately before the program
+exits.  For each source file compiled with \fB\-fprofile\-arcs\fR, the
+profiling code first attempts to read in an existing \fI.gcda\fR file; if
+the file doesn't match the executable (differing number of basic block
+counts) it will ignore the contents of the file.  It then adds in the
+new execution counts and finally writes the data to the file.
+.SS "Using \fBgcov\fP with \s-1GCC\s0 Optimization"
+.IX Subsection "Using gcov with GCC Optimization"
+If you plan to use \fBgcov\fR to help optimize your code, you must
+first compile your program with a special \s-1GCC\s0 option
+\&\fB\-\-coverage\fR.  Aside from that, you can use any
+other \s-1GCC\s0 options; but if you want to prove that every single line
+in your program was executed, you should not compile with optimization
+at the same time.  On some machines the optimizer can eliminate some
+simple code lines by combining them with other lines.  For example, code
+like this:
+.PP
+.Vb 4
+\&        if (a != b)
+\&          c = 1;
+\&        else
+\&          c = 0;
+.Ve
+.PP
+can be compiled into one instruction on some machines.  In this case,
+there is no way for \fBgcov\fR to calculate separate execution counts
+for each line because there isn't separate code for each line.  Hence
+the \fBgcov\fR output looks like this if you compiled the program with
+optimization:
+.PP
+.Vb 4
+\&              100:   12:if (a != b)
+\&              100:   13:  c = 1;
+\&              100:   14:else
+\&              100:   15:  c = 0;
+.Ve
+.PP
+The output shows that this block of code, combined by optimization,
+executed 100 times.  In one sense this result is correct, because there
+was only one instruction representing all four of these lines.  However,
+the output does not indicate how many times the result was 0 and how
+many times the result was 1.
+.PP
+Inlineable functions can create unexpected line counts.  Line counts are
+shown for the source code of the inlineable function, but what is shown
+depends on where the function is inlined, or if it is not inlined at all.
+.PP
+If the function is not inlined, the compiler must emit an out of line
+copy of the function, in any object file that needs it.  If
+\&\fIfileA.o\fR and \fIfileB.o\fR both contain out of line bodies of a
+particular inlineable function, they will also both contain coverage
+counts for that function.  When \fIfileA.o\fR and \fIfileB.o\fR are
+linked together, the linker will, on many systems, select one of those
+out of line bodies for all calls to that function, and remove or ignore
+the other.  Unfortunately, it will not remove the coverage counters for
+the unused function body.  Hence when instrumented, all but one use of
+that function will show zero counts.
+.PP
+If the function is inlined in several places, the block structure in
+each location might not be the same.  For instance, a condition might
+now be calculable at compile time in some instances.  Because the
+coverage of all the uses of the inline function will be shown for the
+same source lines, the line counts themselves might seem inconsistent.
+.PP
+Long-running applications can use the \f(CW\*(C`_\|_gcov_reset\*(C'\fR and \f(CW\*(C`_\|_gcov_dump\*(C'\fR
+facilities to restrict profile collection to the program region of
+interest. Calling \f(CW\*(C`_\|_gcov_reset(void)\*(C'\fR will clear all run-time profile
+counters to zero, and calling \f(CW\*(C`_\|_gcov_dump(void)\*(C'\fR will cause the profile
+information collected at that point to be dumped to \fI.gcda\fR output files.
+Instrumented applications use a static destructor with priority 99
+to invoke the \f(CW\*(C`_\|_gcov_dump\*(C'\fR function. Thus \f(CW\*(C`_\|_gcov_dump\*(C'\fR
+is executed after all user defined static destructors,
+as well as handlers registered with \f(CW\*(C`atexit\*(C'\fR.
+.PP
+If an executable loads a dynamic shared object via dlopen functionality,
+\&\fB\-Wl,\-\-dynamic\-list\-data\fR is needed to dump all profile data.
+.PP
+Profiling run-time library reports various errors related to profile
+manipulation and profile saving.  Errors are printed into standard error output
+or \fB\s-1GCOV_ERROR_FILE\s0\fR file, if environment variable is used.
+In order to terminate immediately after an errors occurs
+set \fB\s-1GCOV_EXIT_AT_ERROR\s0\fR environment variable.
+That can help users to find profile clashing which leads
+to a misleading profile.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+\&\fIgpl\fR\|(7), \fIgfdl\fR\|(7), \fIfsf\-funding\fR\|(7), \fIgcc\fR\|(1) and the Info entry for \fIgcc\fR.
+.SH "COPYRIGHT"
+.IX Header "COPYRIGHT"
+Copyright (c) 1996\-2023 Free Software Foundation, Inc.
+.PP
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3 or
+any later version published by the Free Software Foundation; with the
+Invariant Sections being \*(L"\s-1GNU\s0 General Public License\*(R" and \*(L"Funding
+Free Software\*(R", the Front-Cover texts being (a) (see below), and with
+the Back-Cover Texts being (b) (see below).  A copy of the license is
+included in the \fIgfdl\fR\|(7) man page.
+.PP
+(a) The \s-1FSF\s0's Front-Cover Text is:
+.PP
+.Vb 1
+\&     A GNU Manual
+.Ve
+.PP
+(b) The \s-1FSF\s0's Back-Cover Text is:
+.PP
+.Vb 3
+\&     You have freedom to copy and modify this GNU Manual, like GNU
+\&     software.  Copies published by the Free Software Foundation raise
+\&     funds for GNU development.
+.Ve