 |
» |
|
|
|
|
|
dcpisource(1)
NAME
dcpisource - Augment a DCPI basic-block graph with source code
SYNOPSIS
dcpisource [-src source-file] [-map map-file] [graph-file]
DESCRIPTION
Dcpisource reads a DCPI basic-block graph either from a file specified
on the command line, or from standard input if no files are specified on
the command line. The graph can be generated either by dcpicalc(1) or dcpiflow(1).
If dcpisource can find the source code that corresponds to the basic
block graph, it prints out a graph augmented with the source code, otherwise
it prints out the input graph unchanged. If dcpisource cannot find
the appropriate source file automatically, the user can supply it with the -src flag.
The output of dcpisource can be converted to postscript by dcpi2ps(1).
If the object code was compiled using dcpicc(1),
you may also specify the map file generated by dcpicc. This allows dcpisource to
append to each instruction information on the corresponding source-level
expression. (To reduce cluttering, if a sequence of instructions in the same
basic block correspond to the same source-level expression, the expression
is printed only with the first instruction.) The precision of this information
depends on how the C compiler (which dcpicc invokes) assign source
line numbers to instructions it generates.
FLAGS
- -src source-file
- The source code that is added to the graph is extracted from the specified
source file. The option -f is also accepted for backward compatibility.
- -map map-file
- A map file, produced by dcpicc(1), mapping
line numbers in the object code to the true line and column numbers for
source tokens in the original source file.
LIMITATIONS
How precisely dcpisource identifies the source-level tokens corresponding
to individual instructions depends very much on how the C compiler assigns
source line numbers to the instructions it generates. Generally, with C compilers
for HP Tru64 Unix 4.0 or above, dcpisource indicates for each instruction
the first source token (in textual order) of the source-level expression
for which that instruction is generated. For example, in the following (abbreviated)
output
B0.4 020654 B
309: } else if ((start_pc + (next_inst << 2)) 0
020654 ldl v0, 140(sp) 309: next_inst << 2)) & 0x7) {
020658 s4addq v0, zero, v0
02065c ldq a0, 120(sp) 309: start_pc + (next_inst << 2)) & 0x7) {
020660 addq a0, v0, v0
020664 and v0, 0x7, v0 309: (start_pc + (next_inst << 2)) & 0x7) {
020668 beq v0, 0x120020678 309: if ((start_pc + (next_inst << 2)) & 0x7)
the first two instructions compute the expression next_inst << 2,
the third and fourth compute start_pc + (next_inst << 2), the
fifth computes (start_pc + (next_inst << 2)) & 0x7, and
the final branch instruction implements the if conditional statement
itself. The output does not distinguish between an expression and its (textually)
first sub-expression. For example, in p1->p2->p3->p4, the
instructions for p1->p2 and the subsequent instructions evaluating p1->p2->p3 and
the full p1->p2->p3->p4 would all be attributed to the first
source token, namely p1. The following specific limitations are also
known.
- In a function call, the "top-level" instructions that evaluate the arguments
are attributed to the function call itself, rather than the arguments.
(Instructions evaluating the sub-expressions, however, are correctly attributed.)
For example, in foo(1 + a[i+1], x, y), the instructions computing a[i+1] and
all its sub-expressions are attributed to the appropriate source tokens.
However, the addl instruction that finally evaluates the function
argument is attributed to the function call (and hence to the token for
the function, namely foo).
- In a preprocessor macro with arguments (which textually looks like a
function call), the instructions evaluating the macro, its arguments, or
their sub-expressions are all attributed to the name of the macro.
- When a scalar variable or argument local to a function is moved between
a register and the stack, the load and store instructions are attributed
to the immediately enclosing expression that involves the variable, rather
than the variable itself. For example, if the value of local variable b has
to be loaded from the stack to evaluate a+b, the load instruction
is attributed to the expression a+b (and hence to its textually
first token, a, rather than b).
With some earlier versions of the compiler, instructions are attributed
to a statement, rather than an expression. Specifically, all instructions
calculating the right-hand side of an assignment, as well as the assignment
itself, are attributed to the assignment operator.
TYPICAL USAGE
Typically, dcpisource, dcpicalc(1),
and dcpi2ps(1) are used together as follows:
dcpicalc -db db idle_thread /vmunix | \
dcpisource -src /src/kernel/kern/sched_prim.c | \
dcpi2ps -o idle_thread.ps
SEE ALSO
dcpi(1), dcpi2bb(1), dcpi2pix(1), dcpi2ps(1), dcpicalc(1), dcpicat(1), dcpicc(1), dcpicoverage(1), dcpictl(1), dcpid(1), dcpidiff(1), dcpidis(1), dcpiepoch(1), dcpiflow(1), dcpiflush(1), dcpikdiff(1), dcpilabel(1), dcpildlatency(1), dcpilist(1), dcpiprof(1), dcpiprofileme(1), dcpiquit(1), dcpiscan(1), dcpistats(1), dcpisumxct(1), dcpitar(1), dcpitopcounts(1), dcpitopstalls(1), dcpiuninstall(1), dcpiupcalls(1), dcpivarg(1), dcpivcat(1), dcpiversion(1), dcpivlst(1), dcpivprofiler(1), dcpiwhatcg(1), dcpix(1), dcpiformat(4), dcpiexclusions(4)
For more information, see the DCPI project home page http://h30097.www3.hp.com/dcpi.
COPYRIGHT
Copyright 1996-2004, Hewlett-Packard Company.
All rights reserved.
|
|
