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 AIX binder is not exploited. This section describes some techniques for more efficient use of the binder.
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.
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.
ld -r libfoo.a -o libfooa.o
xlf something.f libfooa.oNotice that the prebound library is treated as another ordinary input file, not with the usual library identification syntax (-lfoo).
xlf something.f a.out
# !/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
The ld command.
The "XCOFF Object (a.out)" File Format.