How does a stripped XCOFF binary still remain usable?

Question

IBM's AIX strip utility documentation states the following:

The strip command with no options removes the line number information, relocation information, symbol table, the debug section, and the typchk section, and the comment section.

If relocation information is removed, how come the stripped executable still remain usable?

Answer 1

COFF files were not designed to support relocation after link-time:

The binary format used initially for Linux was an a.out variant. When introducing shared libraries certain design decisions had to be made to work in the limitations of a.out. The main accepted limitation was that no relocations are performed at the time of loading and afterward. The shared libraries have to exist in the form they are used at run-time on disk. This imposes a major restriction on the way shared libraries are built and used: every shared library must have a fixed load address; otherwise it would not be possible to generate shared libraries which do not have to be relocated.¹

While XCOFF represents an extension of COFF that does support use of shared libraries, the relocation information removed by strip pertains to information used for link-time relocation rather than load- or run-time relocation:

• Reduces the size of an Extended Common Object File Format (XCOFF) object file by removing information used by the binder and symbolic debug program.

• The binder uses the relocation information to modify address constants and other relocatable values when individual XCOFF object files are linked to create an XCOFF executable file.²

The binder appears to play a role similar to that of the link editor ld on Linux systems.

See the description of the -x flag:

Removes the symbol table information but does not remove static or external symbol information. The -x flag also removes relocation information, therefore linking to the file would not be possible.

---

1. How to Write Shared Libraries

2. Relocation Information for XCOFF File (reloc.h)

Answer 2

apparently the XCOFF format has a separate section for dynamic linker (system loader):

Loader Section (loader.h)

The loader section contains information required by the system loader to load and relocate an executable XCOFF object. The loader section is generated by the binder. The loader section has an s_flags section type flag of STYP_LOADER in the XCOFF section header. By convention, .loader is the loader section name. The data in this section is not referenced by entries in the XCOFF symbol table.

Presumably this one is not removed by strip, so the file still works.

See also similar question on what happens with stripped ELF files.