Cachegrind: a cache and branch-prediction profiler
file
::= desc_line* cmd_line events_line da summary_line
desc_line
::= "desc:" ws? non_nl_string
cmd_line
::= "cmd:" ws? cmd
events_line
::= "events:" ws? (event ws)+
data_line
::= file_line | fn_line | count_line
file_line
::= "fl=" filename
fn_line
::= "fn=" fn_name
count_line
::= line_num ws? (count ws)+
summary_line ::= "summary:" ws? (count ws)+
count
::= num | "."
Where:
•
non_nl_string
is any string not containing a newline.
•
cmd
is a string holding the command line of the profiled program.
•
event
is a string containing no whitespace.
•
filename
and
fn_name
are strings.
•
num
and
line_num
are decimal numbers.
•
ws
is whitespace.
The contents of the "desc:" lines are printed out at the top of the summary.
This is a generic way of providing
simulation specific information, e.g. for giving the cache configuration for cache simulation.
More than one line of info can be presented for each file/fn/line number. In such cases, the counts for the named events
will be accumulated.
Counts can be "." to represent zero. This makes the files easier for humans to read.
The number of counts in each
line
and the
summary_line
should not exceed the number of events in the
event_line
.
If the number in each
line
is less, cg_annotate treats those missing as though they were a "."
entry. This saves space.
A
file_line
changes the current file name. A
fn_line
changes the current function name. A
count_line
contains counts that pertain to the current filename/fn_name.
A "fn="
file_line
and a
fn_line
must appear
before any
count_line
s to give the context of the first
count_line
s.
Each
file_line
will normally be immediately followed by a
fn_line
. But it doesn’t have to be.
The summary line is redundant, because it just holds the total counts for each event. But this serves as a useful sanity
check of the data; if the totals for each event don’t match the summary line, something has gone wrong.
92