[ Next Article | Previous Article | Book Contents | Library Home | Legal | Search ]
AIX Versions 3.2 and 4 Performance Tuning Guide

Appendix D. Efficient Use of the ld Command

The AIX binder (invoked as the final stage of a compile or directly via the ld command) has functions that are not found in the typical UNIX linker. This can result in longer linking times if the additional power of the AIXbinder is not exploited. This section describes some techniques for more efficient use of the binder.

Rebindable Executables

The formal documentation of the binder refers to the ability of the binder to take an executable (a load module) as input. Exploitation of this function can significantly improve the overall performance of the system with software-development workloads, as well as the response time of individual lds.

In most typical UNIX systems, the ld command always takes as input a set of files containing object code, either from individual .o files or from archived libraries of .o files. The ld command then resolves the external references among these files and writes an executable with the default name of a.out. The a.out file can only be executed. If a bug is found in one of the modules that was included in the a.out file, the defective source code is changed and recompiled, and then the entire ld process must be repeated, starting from the full set of .o files.

In the AIX operating system, however, the binder can accept both .o and a.out files as input, because the binder includes resolved External Symbol Dictionary (ESD) and Relocation Dictionary (RLD) information in the executable file. This means that the user has the ability to rebind an existing executable to replace a single modified .o file, rather than build a new executable from the beginning. Since the binding process consumes storage and processor cycles partly in proportion to the number of different files being accessed and the number of different references to symbols that have to be resolved, rebinding an executable with a new version of one module is much quicker than binding it from scratch.

Prebound Subroutine Libraries

Equally important in some environments is the ability to bind an entire subroutine library in advance of its use. The system subroutine libraries such as libc.a are, in effect, shipped in binder-output format, rather than as an archive file of .o files. This saves the user considerable processing time when binding an application with the required system libraries, since only the references from the application to the library subroutines have to be resolved. References among the system library routines themselves have already been resolved during the system-build process.

Many third-party subroutine libraries, however, are routinely shipped in archive form as raw .o files. When users bind applications with such libraries, the binder has to do symbol resolution for the entire library each time the application is bound. This results in long bind times in environments where applications are being bound with large libraries on small machines.

The performance difference between bound and unbound libraries is dramatic, especially in minimum configurations. One user reported ld command execution times on the order of 11 minutes in an 8MB Model 320 when binding a small FORTRAN program with an 8+MB subroutine library that had been built in the usual archive form. When the subroutine library was prebound, the time required to bind the FORTRAN program fell to approximately 1.7 minutes. When the resulting a.out file was rebound with a new FORTRAN .o file, simulating the handling of a trivial bug fix, the bind time fell to approximately 4 seconds.

Examples

  1. To prebind a library, use the following command on the archive file:
    ld -r libfoo.a -o libfooa.o
  2. The compile and bind of the FORTRAN program something.f is then:
    xlf something.f libfooa.o

    Notice that the prebound library is treated as another ordinary input file, not with the usual library identification syntax (-lfoo).

  3. To recompile the module and rebind the executable after fixing a bug, use:
    xlf something.f a.out
  4. However, if the bug fix had resulted in a call to a different subroutine in the library, the bind would fail. The following Korn shell script tests for a failure return code and recovers:
    # !/usr/bin/ksh
    # Shell script for source file replacement bind
    #
    xlf something.f a.out
    rc=$?
    if [ "$rc" != 0 ]
    then
       echo "New function added ... using libfooa.o"
       xlf something.o libfooa.o
    fi

Related Information

The ld command.

The XCOFF Object (a.out) File Format.


[ Next Article | Previous Article | Book Contents | Library Home | Legal | Search ]