*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->IRIX man pages -> cord (1)              


CORD(1)								       CORD(1)

NAME    [Toc]    [Back]

     cord - rearranges procedures in an	executable.

SYNOPSIS    [Toc]    [Back]

     cord prog [option]	... [reorder_file] ...

DESCRIPTION    [Toc]    [Back]

     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

     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
	    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

     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.

DIAGNOSTICS    [Toc]    [Back]

     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

									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

FILES    [Toc]    [Back]


SEE ALSO    [Toc]    [Back]

     prof(1), pixie(1)

NOTES    [Toc]    [Back]

     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 ]
 Similar pages
Name OS Title
cord Tru64 Rearrange procedures in an executable file to facilitate better cache mapping
runcord Tru64 invokes cord to rearrange procedures in an executable file to facilitate better cache mapping
runexec IRIX run an executable program described in an executable descriptor file
CSSM_Introduce Tru64 Identify an executable module (CDSA)
a.out OpenBSD format of executable binary files
pixie IRIX add profiling code to an executable file
gzexe IRIX compress executable files in place
elf IRIX Executable and Linking Format (ELF) files
gzexe Linux compress executable files in place
elf OpenBSD format of ELF executable binary files
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service