dcpisource - Augment a DIGITAL Continuous Profiling Infrastructure basic-block graph with source code
dcpisource [-src source-file] [-map map-file] [graph-file]
- -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, mapping line numbers in the object code to the true line and column numbers for source tokens in the original source file.
Dcpisource reads a Continuous Profiling Infrastructure 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 dcpiflow(1) or dcpicalc(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, 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.
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 Digital Unix 4.0 or above, dpisource 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.
Typically, dcpisource, dcpicalc, and dcpi2ps are used together as follows:
dcpicalc -db db idle_thread /vmunix | \ dcpisource -src /src/kernel/kern/sched_prim.c | \ dcpi2ps -o idle_thread.ps
dcpi(1), dcpiflow(1), dcpiprof(1), dcpilist(1), dcpidis(1), dcpiscan(1), dcpiepoch(1), dcpiflush(1), dcpicalc(1), dcpilabel(1), dcpi2ps(1), dcpicat(1), dcpiquit(1), dcpidiff(1), dcpitopstalls(1), dcpiwhatcg(1), dcpictl(1), dcpicc(1), dcpiversion(1), dcpiuninstall(1), dcpi2pix(1), dcpikdiff(1), dcpix(1), dcpisumxct(1), dcpistats(1), dcpid(1), dcpiformat(4), dcpiloader(5)
For more information, see the DIGITAL Continuous Profiling Infrastructure project home page (http://www.research.digital.com/SRC/dcpi/ from outside DIGITAL).
Sanjay Ghemawat, Monika Henzinger, Shun-Tak LeungThis page was generated automatically by mtex software.