HP-UX Linker and Libraries User's Guide

Notice how the program is now linked with /usr/ccs/lib/crt0.o instead of
/opt/langtools/lib/icrt0.o because the profiling code is no longer needed.
Using The flow.data File
By default, the code generator and linker look for the flow.data file in the current working
directory. In other words, the flow.data file created during the profiling phase should be located
in the directory where you relink the program.
Specifying a Different flow.data File with +df
What if you want to use a flow.data file from a different directory than where you are linking?
Or what if you have renamed the flow.data file - for example, if you have multiple flow.data
files created for different input sets? The +df option allows you to override the default +P behavior
of using the file flow.data in the current directory. The compiler passes this option directly to
the linker.
For example, suppose after collecting profile data, you decide to rename flow.data to prog.prf.
You could then use the +df option as follows:
$ cc -v -o prog +P +df prog.prf prog.o
/usr/ccs/bin/ld /usr/ccs/lib/crt0.o -u main -o prog \
+df prog.prf prog.o -P -lc
The +df option overrides the effects of the FLOW_DATA environment variable.
Specifying a Different flow.data with FLOW_DATA
The FLOW_DATA environment variable provides another way to override the default flow.data
file name and location. If set, this variable defines an alternate file name for the profile data file.
For example, to use the file /home/adam/projX/prog.data instead of flow.data, set
FLOW_DATA:
$ FLOW_DATA=/home/adam/projX/prog.data
$ export FLOW_DATA Bourne and Korn shell
$ setenv FLOW_DATA /home/adam/projX/prog.data C shell
Interaction between FLOW_DATA and +df
If an application is linked with +df and -P, the FLOW_DATA environment variable is ignored. In
other words, +df overrides the effects of FLOW_DATA.
Specifying a Different Program Name (+pgm)
When retrieving a program's profile data from the flow.data file, the linker uses the program's
basename as a lookup key. For instance, if a program were compiled as follows, the linker would
look for the profile data under the name foobar:
$ cc -v -o foobar +P foo.o bar.o
/usr/ccs/bin/ld /usr/ccs/lib/crt0.o -u main -o foobar \
foo.o bar.o -P -lc
This works fine as long as the name of the program is the same during the instrumentation and
optimization phases. But what if the name of the instrumented program is not the same as name
of the final optimized program? What does linker do?
Let us say, for example, you want the name of the instrumented application to be different from
the optimized application. So, you use the following compiler commands
$ cc -O +I -o prog.inst prog.c //Instrument prog.inst.
$ prog.inst < input_file1 //Profile it, storing the data under
the name prog.inst.
$ prog.inst < input_file2
Linker Optimizations 211