This chapter describes the linker toolset for Itanium-based system. This toolset provides several tools to help you find symbols, display and modify object files, and determine link order. These tools are specific to ELF (executable and linking format) object file type.

The following lists the linker toolset.

The chatr command (see chatr(1)) allows you to change various program attributes that were determined at link time. When run without any options, chatr displays the attributes of the specified file.

The chatr command supports two different command syntaxes. One is provided for the easy manipulation of simple files. Use it to modify files that have only a single text segment and data segment. The second command syntax allows you to specify selected segments to modify. The following sections list the additional IPF/PA-64 mode options for the chatr command. See the chatr(1) manpage for more information about formats.

The following summarizes the options you can use to change various attributes:

The nm(1) command displays the symbol table of each specified object. The file can be a relocatable object file or an executable object file, or an archive of relocatable or executable object files.

The nm command provides three general output formats: the default (neither -p nor -P specified), -p, and -P. See the nm(1) man page for a detailed description of the output formats.

Examples

• Display which object files have undefined references for the symbol leap:

  nm -rup *.o | grep leap

• Display which object files have a definition for the text symbol leap:

  nm -rP *.o | awk '{ if ($3 == "T" && $2 == "leap" ) { print $0 } }'

• To view the symbols defined in an object file, use the nm command. The following 32-bit mode example shows output from running nm -p on the func.o and main.o object files.

  $ nm -p func.o

  	0000000000 u  
  	0000000000 r  .HP.opt_annot
  	0000000000 r  .IA_64.unwind_info
  	0000000000 r  .text
  	0000000000 a  func.c
  	0000000000 T  sum_n                 //Global definitions of sum_n.
  	$ nm -p main.o
  	0000000000 U  $global$              //Other symbols created from compiling.
  	0000000000 u  
  	0000000000 r  .HP.opt_annot
  	0000000000 r  .IA_64.unwind_info
  	0000000000 r  .data
  	0000000000 r  .sdata
  	0000000000 r  .text
  	0000000000 a  main.c
  	0000000000 T  main                   //Global definition of main.
  	0000000000 U  printf
  	0000000000 U  scanf
  	0000000000 U  sum_n
  	

The elfdump(1) command displays information contained in ELF format object files, archives, and shared libraries.

Use the following options to select the information you want to display:

The elfdump command provides the following additional options to modify your selections:

The ldd(1) command lists the dynamic dependencies of executable files or shared libraries. The ldd command displays verbose information about dynamic dependencies and symbol references:

Executable

All shared libraries loaded as a result of executing the file.

Shared library

All shared libraries loaded as a result of loading the library.

The ldd command uses the same algorithm as the dynamic loader (/usr/lib/hpux32/dld.so and /usr/lib/hpux64/dld.so) to locate the shared libraries.

The ldd command does not list shared libraries explicitly loaded using dlopen(3C) or shl_load(3X).

The ldd command prints the record of shared library path names to stdout. It prints a list of symbol resolution problems to stderr.

Examples

• By default, ldd prints simple dynamic path information, including the dependencies recorded in the executable (or the shared library) followed by the physical location where the dynamic loader finds these libraries.

  $ ldd a.out

  	./libx.so =>	./libx.so
  		libc.so.1 =>	/usr/lib/hpux32/libc.so.1
  		libdl.so.1 =>	/usr/lib/hpux32/libdl.so.1
  	

• The -v option causes ldd to print the dependency relationships along with the dynamic path information.

  $ ldd -v a.out

  	find library=./libx.so; required by a.out 
  		./libx.so =>	./libx.so 
  	find library=libc.so.1; required by a.out 
  		libc.so.1 =>	/usr/lib/hpux32/libc.so.1
  	find library=libdl.so.1; required by usr/lib/hpux32/libc.so.1
  		libdl.so.1 =>	/usr/lib/hpux32/libdl.so.1 
  	

• The -r option to causes it to analyze all symbol references and print information about unsatisfied code and data symbols.

  $ldd -r a.out

  	./libx.sl	=>	./libx.sl
  	libc.so.1	=>	/usr/lib/hpux32/libc.so.1
  	libdl.1	=>	/usr/lib/hpux32/libdl.so.1
  	symbol not found: val1 (./libx.so)
  	symbol not found: count (./libx.so)
  	symbol not found: func1 (./libx.so)
  	symbol not found: func2 (./libx.so)
  	

Given a process ID (PID) or a corefile, the pldd command prints a list of shared libraries loaded including those loaded explicitly with dlopen() and shl_load(). The pldd command works by attaching to the process to read its memory. Mismatch between executable and corefile may result in unpredictable behavior.

The pldd command searches for the executable file in the current directory and $PATH. The executable path can be specified along with the pid/corepath, separated by a colon (:) character.

Use the -h option to print the usage menu.

The following exit values are returned:
0: Successful operation
non-zero: An error has occurred.

Given the PID of a running process or the full path to a corefile, the pstack command prints the stack trace for each lwp thread in the process. To obtain symbol information, pstack searches load modules (executable/shared libraries) in the current directory, $PATH, $LD_LIBRARY_PATH, and $SHLIB_PATH. The executable path can be specified along with the PID/core-file-path, separated by a colon (:) character. If a load module is not found, symbol information for frames in that module is not displayed.

The pstack command works by attaching to the running process and reading its registers, memory, and stack. Mismatch between executable and corefile may result in unpredictable behavior.

The following exit values are returned:
0: Successful operation
non-zero: An error has occurred.

The size(1) command produces section size information for each section in your specified object files. It displays the size of the text, data, and bss (uninitialized data) sections with the total size of the object file. If you specify an archive file, the information for all archive members is displayed.

Use the following options to view information for your specified files:

The strip(1) command removes the symbol table and line number information from object files, including archives. Thereafter, no symbolic debugging access is available for that file. The purpose of this command is to reduce file storage overhead consumed by the object file. Use this command on production modules that have been debugged and tested. The effect is nearly identical to using the -s option of ld.

You can control the amount of information stripped from the symbol table by using the following options:

The -l and -x options are synonymous because the symbol table contains only static and external symbols. Either option strips only symbolic debugging information and unloadable data.

If there are any relocation entries in the object file and any symbol table information is to be stripped, strip issues a message and terminates without stripping the specified file unless the -r option is used.

If you execute strip on an archive file (see ar(4)), it removes the archive symbol table. The archive symbol table must be restored by executing ar with its s operator (see ar(1)) before the ld command (see ld (1)) can use the archive. The strip command issues appropriate warning messages when this situation occurs.

The fastbind(1) command prepares an incomplete executable for faster program start-up. It can improve the start-up time of programs that use shared libraries (incomplete executables) by storing information about needed shared library symbols in the executable file.

The fastbind command performs analysis on the symbols used to bind an executable and all of its dependent shared libraries, and stores this information in the executable file. The next time the executable is run, the dynamic loader (/usr/lib/hpux32/dld.so for 32-bit or /usr/lib/hpux64/dld.so for 64-bit) detects that this information is available, and uses it to bind the executable instead of using the standard search method for binding the symbols.

The fastbind command writes the fastbind information in the executable file. Hence, you must have write permission on the executable file. If the executable file being analyzed is being run as another process or the file is locked against modifications by the kernel, the fastbind command fails.

If the shared libraries that an executable is dependent on are modified after the fastbind information is created, the dynamic loader silently reverts to standard search method for binding the symbols. The fastbind information can be re-created by running the fastbind command on the executable again. The fastbind command automatically erases the old fastbind information and generates the new one.

The PA-32-bit mode fastbind command does not work with EXEC_MAGIC executables.

The fastbind command effectively enforces the binding modes bind-restricted and bind-immediate. For example, consider an executable linked bind-deferred, which calls a function foo() defined in an implicitly loaded library. Before the actual call is made, if it explicitly loads a shared library (using shl_load(3X) with BIND_FIRST) having a definition for foo() when foo() is finally called, it is resolved from the explicitly-loaded library. But after running fastbind, the symbol foo() is resolved from the implicitly-loaded library.

For more information about fastbind and how to improve program start-up time, see Improving Shared Library Start-Up Time with fastbind .

• To run fastbind on the executable file a.out:

  $fastbind a.out

• To later remove the fastbind information from the executable file a.out

  $fastbind -n a.out

The lorder command finds the ordering relation for an object library. You can specify one or more object or archive library files (see ar(1)) on the command line or read those files from standard input. The standard output is a list of pairs of object file names, meaning that the first file of the pair refers to external identifiers defined in the second.

You can process the output with tsort to find an ordering of a library suitable for one-pass access by ld (see tsort(1) and ld(1)). The linker ld is capable of multiple passes over an archive in the archive format and does not require that you use lorder when building an archive. Using the lorder command may, however, allow for a slightly more efficient access of the archive during the link-edit process.

The symbol table maintained by ar allows ld to randomly access symbols and files in the archive, making the use of lorder unnecessary when building archive libraries (see ar(1)).

The lorder command overlooks object files whose names do not end with .o, even when contained in library archives, and attributes their global symbols and references to some other file.

• Build a new library from existing .o files:

  $ar cr library `lorder *.o | tsort`

• When creating libraries with so many objects that the shell cannot properly handle the *.o expansion, the following technique may prove useful:

  $ls |grep '.o$'|lorder|tsort|xargs ar cq library