CORD(1) CORD(1)
cord - rearranges procedures in an executable.
cord prog [option] ... [reorder_file] ...
The cord(1) command can be used to rearrange procedures in an executable
object to correspond with an ordering provided in a reorder_file.
Normally, the ordering is arranged to reduce virtual memory paging and/or
instruction cache misses. The reorder file can be produced by the
-feedback option to prof (see prof(1)). The -gprof -feedback options in
prof can be used to produce a procedure ordering based on the function
call counts. The default reorder file is prog.pixie.fb (if that does not
exist, prog.fb is used if prog.fb exists). You can also hand-optimize
the reorder file by rearranging the procedure entries in the reorder
file.
In the example below, a program foo is run through pixie(1) which
generates foo.pixie. The instrumented executable is run and prof is used
to produce a feedback file from the profiled data. Cord is then used to
reorder the procedures in foo, generating a new binary foo.cord.
pixie foo
foo.pixie
prof -pixie -feedback foo
cord foo foo.pixie.fb
The degree and specifics of procedure rearrangement depend on the data
produced by the profiled runs of the executable. The more closely these
profiled runs approximate the actual use of the executable, the closer to
optimal the resulting rearrangement will be. Design your profiled runs
accordingly.
Multiple reorder files can be specified in the command line. The first
reorder file has the highest priority in rearranging the ordering. This
feature can be used to improve performance in different program phases,
if the multiple feedback files are generated by executing different
phases of the program.
The cord command accepts these options:
-merge mergefile
Specifies the "merged" reorder file. The final procedure
ordering is listed in this file. When multiple reorder files
are specified in the command line, the file represents a merged
ordering of those files. When only one reorder file is
provided, the final order may still be different from specified
in the reorder file. The reasons can be to workaround CPU bugs,
procedures not specified in the reorder file, or procedures
tied together by semantic constraints.
Page 1
CORD(1) CORD(1)
-o outfile
Specifies the output file. If this option is not specified,
prog.cord is used.
-t Prints a report of procedures tied together (procedures that
cannot be separated, regardless of other ordering
considerations). This essentially always means the procedures
are hand-written assembler. If procedures cannot be separated
because one falls thru into another or has some other special
non-branch connection an M (to suggest merged procedures) is
printed on the report line. If procedures cannot be separated
because one explicitly branches into another, the letter B is
printed on the report line. If both characteristics apply then
both letters are printed. If a sequence of procedures (more
than two) are tied together, then the second and subsequent in
the sequence show a blank name as the first procedure name.
Sample output:
Note: _sproc tied to _sprocsp MB
Note: tied to _nsproc MB
-v Prints verbose information. This includes listing procedures
considered part of other procedures and therefore cannot be
rearranged (these are basically assembler procedures that may
contain relative branches to other procedures rather than
relocatable ones). The listing also shows conflicts between
procedures in the binary and in the reorder file.
-B For old 32bit ABI binaries with more than 64K procedures (this
is a very exceptional case) this option results in a more
certain correct update of the .mdebug section data. The
.mdebug section is used by debuggers: it does not affect
program execution. Do not use this option unless you know
positively you have more than 64K procedures in the old 32bit
ABI binary being corded.
The message
Warning: Use cord -v to see procedures in binary that are not in
feedback file.
means that the feedback file does not list every procedure in the binary.
The message
Warning: Use cord -v to see procedures in feedback file that are not
in binary.
means that the feedback file lists procedures that do not exist in the
binary.
Page 2
CORD(1) CORD(1)
These are normally harmless warnings, but if you are not expecting any
name mismatches, rerun cord with the -v option to see what procedures
mismatched.
/usr/bin/cord
prof(1), pixie(1)
For C++, feedback files input to cord normally have the mangled C++
function name. cord matches the procedure names from a feedback file
against both the mangled or unmangled procedure names (as extracted from
the debugging information) and accepts a match on either (when combined
with a match against the base file name (the file with all path prefixes
stripped off)). The unmangled name cord uses does not have a class name
prefix, so the unmangled form is not very safe to use.
Inlined functions cannot be touched by cord: the non-inlined procedures
are all that can usefully be corded.
PPPPaaaaggggeeee 3333 [ Back ]
|
