Browse Prior Art Database

Creating a Compact Relocatable Binary

IP.com Disclosure Number: IPCOM000115934D
Original Publication Date: 1995-Jul-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 4 page(s) / 156K

Publishing Venue

IBM

Related People

Bealkowski, R: AUTHOR [+3]

Abstract

Disclosed is a method to extract a compact executable file with relocation information from an XCOFF object file at build time, and then process the compacted file at run-time. This technique is especially useful in resource constrained environments such as during the execution of the system firmware.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 46% of the total text.

Creating a Compact Relocatable Binary

      Disclosed is a method to extract a compact executable file with
relocation information from an XCOFF object file at build time, and
then process the compacted file at run-time.  This technique is
especially useful in resource constrained environments such as during
the execution of the system firmware.

      The eXtended Common Object File Format (XCOFF) definition
allows for various object file attributes and sections.  AIX*
compilers, linkers and utilities typically use this format when
working with object modules.  This standard can describe an object
file after compilation as well as the bound executable module
produced by the linker.  The XCOFF definition has provisions for
program instructions (text section), initialized data fields (data
section), uninitialized data fields (BSS section) and loader
information (loader section).  The The XCOFF object file does not
include a raw data area for the BSS section; instead it includes a
header that defines the BSS section size.  At load-time, the
operating system uses the header to allocate memory for the BSS
section of the object file.  The The BSS section is used to contain
the uninitialized data section; therefore no raw data area is
allocated in the XCOFF object file.

      Additionally, an XCOFF file can have file/section headers,
sections for debugger usage and sections for linker usage (e.g.,
symbol tables, string tables, line number information, etc.).
Although these sections help the use and re-use of the object module,
they add significantly to the object module size.  Also, there is
some duplication between the loader section and the master symbol
table, string table and relocation information.  The loader section
for an executable XCOFF file has the combined and resolved versions
of the string table, symbol table and relocation information.  The
linker builds the loader section by combining and resolving the
master symbol table, string table and relocation table sections of
the input object module(s).  However, the master symbol table, string
table and relocation table are not discarded; they are retained to
allow re-linking and debugging of the executable object module.  In
an environment where re-linking and debug support is not required,
the duplicated sections are unnecessary overhead.

      In the AIX operating system, the strip command can be used to
discard certain portions of the XCOFF object file.  However, this
command does not allow for the optimal extraction - only the text,
data and minimum relocation portions of the XCOFF object file.  The
best combination of the strip parameters still leaves the entire
loader section intact, which can amount to ten percent of the
executable size.  Notice that a minimized executable file does not
require the loader section's symbol and string tables.

      A build process is used to translate XCOFF object files into
compact, relocatable binary files. ...