cord(1)
cord - Rearranges procedures in an executable object
As shipped in IRIX 6.5.15. Last changed in IRIX 6.5.5.
NAME cord - Rearranges procedures in an executable object SYNOPSIS cord prog [option] ... [reorder_file] ... IMPLEMENTATION IRIX systems DESCRIPTION The cord(1) command can be used to rearrange procedures in an executable object to correspond with an ordering provided in a reorder_file. Usually, 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 You can also have the linker do the reordering. See the MIPSpro Compiling and Performance Tuning Guide or the ld(1) man page. 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 the following 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. -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 32-bit 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. DIAGNOSTICS file. Warning: Use cord - v to see procedures in binary that are not in feedback This message means that the feedback file does not list every procedure in the binary. binary. Warning: Use cord - v to see procedures in feedback file that are not in This message means that the feedback file lists procedures that do not exist in the binary. These are usually harmless warnings, but if you are not expecting any name mismatches, rerun cord with the -v option to see which procedures mismatched. NOTES For C++, feedback files input to cord usually 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. FILES /usr/bin/cord SEE ALSO prof(1), pixie(1), and ld(1) This man page is available only online.