a.out_800(4) — Series 700/800 Implementation

NAME

a.out − assembler and link editor output

SYNOPSIS

#include <a.out.h>

Remarks:

This manual page describes the a.out file format for Series 700 and Series 800 computers. Refer to other a.out(4) manual entries for descriptions of other valid implementations.

DESCRIPTION

The file name a.out is the output file from the assembler as(1), compilers, and the linker ld(1). The assembler and compilers create relocatable object files ready for input to the linker; the linker creates executable object files and shared library files.

An object file consists of a file header, auxiliary headers, space dictionary, subspace dictionary, symbol table, relocation information, compiler records, space string table, symbol string table, and the data for initialized code and data. Not all of these sections are required for all object files. The file must begin with the file header, but the remaining sections do not have to be in any particular order; the file header contains pointers to each of the other sections of the file.

A relocatable object file, created by the assembler or compiler, must contain at least the following sections: file header, space dictionary, subspace dictionary, symbol table, relocation information, space string table, symbol string table, and code and data. It may also contain auxiliary headers and compiler records. Relocatable files generally contain unresolved symbols; the linker combines relocatable files and searches libraries to produce an executable file. The linker can also be used to combine relocatable files and produce a new relocatable file as output, suitable for input to a subsequent linker run.

An executable file, created by the linker, typically contains the following sections: file header, an HP-UX auxiliary header, space dictionary, subspace dictionary, symbol table, space string table, symbol string table, and code and data. The linker also copies any auxiliary headers and compiler records from the input files to the output file. If the file has been stripped (see strip(1)), it will not contain a symbol table, symbol string table, or compiler records. An executable file must not contain any unresolved symbols.

A shared library file, created by the linker, contains the same sections found in an executable file, with additional information added to the code section of the file. This additional information contains a header, export table, import table, and dynamic relocation records to be used by the dynamic loader.

Programs for the Series 700/800 architecture consist of two loadable spaces: a shared, non-writable, code space named “$TEXT$”; and a private, writable, data space named “$PRIVATE$”. A program may contain other non-loadable spaces that contain data needed by development tools; for example, symbolic debugging information is contained in a space named “$DEBUG$”. The linker treats loadable and unloadable spaces exactly the same, so the full generality of symbol resolution and relocation is available for the symbolic debugging information. Spaces have an addressing range of 4,294,967,296 (2^32) bytes; each loadable space is divided into four 1,073,741,824 (2^30) byte quadrants. The HP-UX operating system places all code in the first quadrant of the $TEXT$ space, all data in the second quadrant of the $PRIVATE$ space, and all shared library code into the third quadrant of shared memory space.

Each space is also divided into logical units called subspaces. When the linker combines relocatable object files, it groups all subspaces from the input files by name, then arranges the groups within the space by a sort key associated with each subspace. Subspaces are not architecturally significant; they merely provide a mechanism for combining individual parts of spaces independently from many input files. Some typical subspaces in a program are shown in the following table:

$SHLIB_INFO$	Information needed for dynamic loading.
$MILLICODE$	Code for millicode routines
$LIT$	Sharable literals
$CODE$	Code
$UNWIND$	Stack unwind information
$GLOBAL$	Outer block declarations for Pascal
$DATA$	Static initialized data
$COMMON$	FORTRAN common
$SHLIB_DATA$	Imported data from referenced shared libraries.
$BSS$	Uninitialized data

Subspaces can be initialized or uninitialized (although typically, only $BSS$ is uninitialized). The subspace dictionary entry for an initialized subspace contains a file pointer to the initialization data, while the entry for an uninitialized subspace contains only a 32-bit pattern used to initialize the entire area at load time.

In a relocatable file, initialized code and data often contains references to locations elsewhere in the file, and to unresolved symbols defined in other files. These references are patched at link time using the relocation information. Each entry in the relocation information (a “fixup”) specifies a location within the initialized data for a subspace, and an expression that defines the actual value that should be placed at that location, relative to one or two symbols.

The linker summarizes the subspace dictionary in the HP-UX auxiliary header when creating an executable file. HP-UX programs contain only three separate sections: one for the code, one for initialized data, and one for uninitialized data. By convention, this auxiliary header is placed immediately following the file header.

When an a.out file is loaded into memory for execution, three areas of memory are set up: the a.out code is loaded into the first quadrant of a new, sharable space; the data (initialized followed by uninitialized) is loaded into the second quadrant of a new, private space; and a stack is created beginning at a fixed address near the middle of the second quadrant of the data space.

If the a.out file uses shared libraries then the dynamic loader /lib/dld.sl is loaded into memory, and called to map all shared libraries, requested by the program, into memory. The shared library text is loaded into the third quadrant of the shared memory space, and the shared library data is allocated in the second quadrant of the data space.

The file format described here is a common format for all operating systems designed for HP’s Precision Architecture. Therefore, there are some fields and structures that are not used on HP-UX or have been reserved for future use.

File Header

The format of the file header is described by the following structure declaration from <filehdr.h>.

struct header {
short int system_id;/* system id */
short int a_magic;/* magic number */
unsigned int version_id;/* a.out format version */
struct sys_clock file_time;/* timestamp */
unsigned int entry_space;/* reserved */
unsigned int entry_subspace;/* reserved */
unsigned int entry_offset;/* reserved */
unsigned int aux_header_location;/* file ptr to aux hdrs */
unsigned int aux_header_size;/* sizeof aux hdrs */
unsigned int som_length;/* length of object module */
unsigned int presumed_dp;/* reserved */
unsigned int space_location;/* file ptr to space dict */
unsigned int space_total;/* # of spaces */
unsigned int subspace_location;/* file ptr to subsp dict */
unsigned int subspace_total;/* # of subspaces */
unsigned int loader_fixup_location;/* reserved */
unsigned int loader_fixup_total;/* reserved */
unsigned int space_strings_location;/* file ptr to sp. strings */
unsigned int space_strings_size;/* sizeof sp. strings */
unsigned int init_array_location;/* reserved */
unsigned int init_array_total;/* reserved */
unsigned int compiler_location;/* file ptr to comp recs */
unsigned int compiler_total;/* # of compiler recs */
unsigned int symbol_location;/* file ptr to sym table */
unsigned int symbol_total;/* # of symbols */
unsigned int fixup_request_location;/* file ptr to fixups */
unsigned int fixup_request_total;/* # of fixups */
unsigned int symbol_strings_location;/* file ptr to sym strings */
unsigned int symbol_strings_size;/* sizeof sym strings */
unsigned int unloadable_sp_location;/* file ptr to debug info */
unsigned int unloadable_sp_size;/* size of debug info */
unsigned int checksum;/* header checksum */
};

The timestamp is a two-word structure as shown below. If unused, both fields are zero.

struct sys_clock {
unsigned int secs;
unsigned int nanosecs;
};

Auxiliary Headers

The auxiliary headers are contained in a single contiguous area in the file, and are located by a pointer in the file header. Auxiliary headers are used for two purposes: users can attach version and copyright strings to an object file, and an auxiliary header contains the information needed to load an executable program. In an executable program, the HP-UX auxiliary header must precede all other auxiliary headers. The following declarations are found in <aouthdr.h>.

struct aux_id {
unsigned intmandatory : 1;/* reserved */
unsigned intcopy : 1;/* reserved */
unsigned intappend : 1;/* reserved */
unsigned intignore : 1;/* reserved */
unsigned intreserved : 12;/* reserved */
unsigned inttype : 16;/* aux hdr type */
unsigned intlength;/* sizeof rest of aux hdr */
};

/* Values for the aux_id.type field */
#define HPUX_AUX_ID4
#define VERSION_AUX_ID6
#define COPYRIGHT_AUX_ID9
#define SHLIB_VERSION_AUX_ID10

struct som_exec_auxhdr {/* HP-UX auxiliary header */
struct aux_idsom_auxhdr; /* aux header id */
longexec_tsize;/* text size */
longexec_tmem;/* start address of text */
longexec_tfile;/* file ptr to text */
longexec_dsize;/* data size */
longexec_dmem;/* start address of data */
longexec_dfile;/* file ptr to data */
longexec_bsize;/* bss size */
longexec_entry;/* address of entry point */
longexec_flags;/* loader flags */
longexec_bfill;/* bss initialization value */
};

/* Values for exec_flags */
#define TRAP_NIL_PTRS01

struct user_string_aux_hdr {/* Version string auxiliary header */
struct aux_idheader_id;/* aux header id */
unsigned intstring_length;/* strlen(user_string) */
charuser_string[1];/* user-defined string */
};

struct copyright_aux_hdr {/* Copyright string auxiliary header */
struct aux_idheader_id;/* aux header id */
unsigned intstring_length;/* strlen(user_string) */
charcopyright[1];/* user-defined string */
};
struct shlib_version_aux_hdr {
struct aux_idheader_id;/* aux header id */
shortversion;/* version number */
};

Space Dictionary

The space dictionary consists of a sequence of space records as defined in <spacehdr.h>.

struct space_dictionary_record {
union name_ptname;/* index to space name */
unsigned intis_loadable: 1;/* space is loadable */
unsigned intis_defined: 1;/* space is defined within file */
unsigned intis_private: 1;/* space is not sharable */
unsigned intreserved: 13;/* reserved */
unsigned intsort_key: 8;/* sort key for space */
unsigned intreserved2: 8;/* reserved */
intspace_number;/* space index */
intsubspace_index;/* index to first subspace */
unsigned intsubspace_quantity;/* # of subspaces in space */
intloader_fix_index;/* reserved */
unsigned intloader_fix_quantity; /* reserved */
intinit_pointer_index;/* reserved */
unsigned intinit_pointer_quantity; /* reserved */
};

The strings for the space names are contained in the space strings table, which is located by a pointer in the file header. Each entry in the space strings table is preceded by a 4-byte integer that defines the length of the string, and is terminated by at one to five null characters to pad the string out to a word boundary. Indices to this table are relative to the start of the table, and point to the first byte of the string (not the preceding length word). The union defined below is used for all such string pointers; the character pointer is defined for programs that read the string table into memory and wish to relocate in-memory copies of space records.

union name_pt {
char *n_name;
unsigned intn_strx;
};

Subspace Dictionary

The subspace dictionary consists of a sequence of subspace records as defined in <scnhdr.h>. Strings for subspace names are contained in the space strings table.

struct subspace_dictionary_record {
intspace_index;
unsigned intaccess_control_bits: 7; /* reserved */
unsigned intmemory_resident: 1; /* reserved */
unsigned intdup_common: 1;/* COBOL-style common */
unsigned intis_common: 1;/* subspace is a common block */
unsigned intis_loadable: 1;/* subspace is loadable */
unsigned intquadrant: 2;/* reserved */
unsigned intinitially_frozen: 1;/* reserved */
unsigned intis_first: 1;/* reserved */
unsigned intcode_only: 1;/* subspace contains only code */
unsigned intsort_key: 8;/* subspace sort key */
unsigned intreplicate_init: 1;/* reserved */
unsigned intcontinuation: 1;/* reserved */
unsigned intreserved: 6;/* reserved */
intfile_loc_init_value;/* file location or init value */
unsigned intinitialization_length; /* length of initialization */
unsigned intsubspace_start;/* starting offset */
unsigned intsubspace_length;/* total subspace length */
unsigned intreserved2: 16;/* reserved */
unsigned intalignment: 16;/* alignment required */
union name_ptname;/* index of subspace name */
intfixup_request_index; /* index to first fixup */
unsigned intfixup_request_quantity; /* # of fixup requests */
};

Symbol Table

The symbol table consists of a sequence of entries described by the structure shown below, from <syms.h>. Strings for symbol and qualifier names are contained in the symbol strings table, whose structure is identical with the space strings table.

struct symbol_dictionary_record {
unsigned inthidden: 1;/* reserved */
unsigned intsymbol_type: 7;/* symbol type */
unsigned intsymbol_scope: 4;/* symbol value */
unsigned intcheck_level: 3;/* type checking level */
unsigned intmust_qualify: 1;/* qualifier required */
unsigned intinitially_frozen: 1;/* reserved */
unsigned intmemory_resident: 1; /* reserved */
unsigned intis_common: 1;/* common block */
unsigned intdup_common: 1;/* COBOL-style common */
unsigned intxleast: 2;/* reserved */
unsigned intarg_reloc: 10;/* parameter relocation bits */
union name_ptname;/* index to symbol name */
union name_ptqualifier_name;/* index to qual name */
unsigned intsymbol_info;/* subspace index */
unsigned intsymbol_value;/* symbol value */
};

/* Values for symbol_type */
#define ST_NULL0/* unused symbol entry */
#define ST_ABSOLUTE1/* non-relocatable symbol */
#define ST_DATA2/* data symbol */
#define ST_CODE3/* generic code symbol */
#define ST_PRI_PROG4/* program entry point */
#define ST_SEC_PROG5/* secondary prog entry pt.*/
#define ST_ENTRY6/* procedure entry point */
#define ST_STORAGE7/* storage request */
#define ST_STUB8/* reserved */
#define ST_MODULE9/* Pascal module name */
#define ST_SYM_EXT10/* symbol extension record */
#define ST_ARG_EXT11/* argument extension record */
#define ST_MILLICODE12/* millicode entry point */
#define ST_PLABEL13/* reserved */
#define ST_OCT_DIS14/* reserved */
#define ST_MILLI_EXT15/* reserved */

/* Values for symbol_scope */
#define SS_UNSAT0/* unsatisfied reference */
#define SS_EXTERNAL1/* reserved */
#define SS_LOCAL2/* local symbol */
#define SS_UNIVERSAL3/* global symbol */

The meaning of the symbol value depends on the symbol type. For the code symbols (generic code, program entry points, procedure and millicode entry points), the low-order two bits of the symbol value encode the execution privilege level, which is not used on HP-UX, but is generally set to 3. The symbol value with those bits masked out is the address of the symbol (which is always a multiple of 4). For data symbols, the symbol value is simply the address of the symbol. For storage requests, the symbol value is the number of bytes requested; the linker allocates space for the largest request for each symbol in the $BSS$ subspaces, unless a local or universal symbol is found for that symbol (in which case the storage request is treated like an unsatisfied reference).

If a relocatable file is compiled with parameter type checking, extension records follow symbols that define and reference procedure entry points and global variables. The first extension record, the symbol extension record, defines the type of the return value or global variable, and (if a procedure or function) the number of parameters and the types of the first three parameters. If more parameter type descriptors are needed, one or more argument extension records follow, each containing four more descriptors. A check level of 0 specifies no type checking; no extension records follow. A check level of 1 or more specifies checking of the return value or global variable type. A check level of 2 or more specifies checking of the number of parameters, and a check level of 3 specifies checking the types of each individual parameter. The linker performs the requested level of type checking between unsatisfied symbols and local or universal symbols as it resolves symbol references.

union arg_descriptor {
struct {
unsigned intreserved: 3;/* not used */
unsigned intpacking: 1;/* reserved */
unsigned intalignment: 4;/* byte alignment */
unsigned intreserved2: 1;/* not used */
unsigned intmode: 3;/* use of symbol */
unsigned intstructure: 4;/* structure of symbol */
unsigned inthash: 1;/* set if arg_type is hashed */
intarg_type: 15;/* data type */
}arg_desc;
unsigned intword;
};
struct symbol_extension_record {
unsigned inttype: 8;/* always ST_SYM_EXT */
unsigned intmax_num_args: 8;/* max # of parameters */
unsigned intmin_num_args: 8;/* min # of parameters */
unsigned intnum_args: 8;/* actual # of parameters */
union arg_descriptor symbol_desc;/* symbol type desc. */
union arg_descriptor argument_desc[3]; /* first 3 parameters */
};
struct argument_desc_array {
unsigned inttype: 8;/* always ST_ARG_EXT */
unsigned intreserved: 24;/* not used */
union arg_descriptor argument_desc[4]; /* next 4 parameters */
};

The values for the alignment, mode, structure, and arg_type (when the data type is not hashed) fields are given in the following table.

value	alignment	mode	structure	arg_type
0	byte	any	any	any
1	half-word	value parm	scalar	void
2	word	reference parm	array	signed byte
3	dbl word	value-result	struct	unsigned byte
4		name	pointer	signed short
5		variable	long ptr	unsigned short
6	64-byte	function return	C string	signed long
7		procedure	Pascal string	unsigned long
8		long ref parm	procedure	signed dbl word
9			function	unsigned dbl word
10			label	short real
11	page			real
12				long real
13				short complex
14				complex
15				long complex
16				packed decimal
17				struct/array

For procedure entry points, the parameter relocation bits define the locations of the formal parameters and the return value. Normally, the first four words of the parameter list are passed in general registers (r26−r23) instead of on the stack, and the return value is returned in r29. Floating-point parameters in this range are passed instead in floating-point registers (fr4−fr7) and a floating-point value is returned in fr4. The parameter relocation bits consist of five pairs of bits that describe the first four words of the parameter list and the return value. The leftmost pair of bits describes the first parameter word, and the rightmost pair of bits describes the return value. The meanings of these bits are shown in the following table.

bits	meaning
00	no parameter or return value
01	parameter or return value in general register
10	parameter or return value in floating-point register
11	double-precision floating-point value

For double-precision floating-point parameters, the odd-numbered parameter word should be marked ‘11’ and the even-numbered parameter word should be marked ‘10’. Double-precision return values are simply marked ‘11’.

Every procedure call is tagged with a similar set of bits (see Relocation Information, below), so that the linker can match each call with the expectations of the procedure entry point. If the call and entry point mismatch, the linker creates a stub that relocates the parameters and return value as appropriate.

Relocation Information

Each initialized subspace defines a range of fixups that apply to the data in that subspace. A fixup request is associated with every word that requires relocation or that contains a reference to an unsatisfied symbol. In relocatable object files created prior to HP-UX Release 3.0 on Series 800, each fixup request is a five-word structure that describes a code or data word to be patched at link time. Object files created on Release 3.0 or later contain variable-length fixup requests that describe every byte of the subspace. The version_id field in the file header distinguishes these two formats; the constant VERSION_ID is found in older object files, and the constant NEW_VERSION_ID is found in newer ones.

In older object files, fixups can compute an expression involving zero, one, or two symbols and a constant, then extract a field of bits from that result and deposit those bits in any of several different formats (corresponding to the Precision Architecture instruction set). The fixup_request_index field in the subspace dictionary entry indexes into the fixup request area defined by the file header, and the fixup_request_quantity field refers to the number of fixup requests used for that subspace. The structure of a fixup request is contained in <reloc.h>.

struct fixup_request_record {
unsigned intneed_data_ref: 1;/* reserved */
unsigned intarg_reloc: 10;/* parameter relocation bits */
unsigned intexpression_type: 5;/* how to compute value */
unsigned intexec_level: 2;/* reserved */
unsigned intfixup_format: 6;/* how to deposit bits */
unsigned intfixup_field: 8;/* field to extract */
unsigned intsubspace_offset;/* subspace offset of word */
unsigned intsymbol_index_one;/* index of first symbol */
unsigned intsymbol_index_two;/* index of second symbol */
intfixup_constant;/* constant */
};

/* Values for expression_type */
#define e_one0/* symbol1 + constant */
#define e_two1/* symbol1 − symbol2 + constant */
#define e_pcrel2/* symbol1 − pc + constant */
#define e_con3/* constant */
#define e_plabel7/* symbol1 + constant */
#define e_abs18/* reserved */

/* Values for fixup_field (assembler mnemonics shown) */
#define e_fsel0/* F’: no change */
#define e_lssel1/* LS’: inverse of RS’ */
#define e_rssel2/* RS’: rightmost 11 bits, signed */
#define e_lsel3/* L’: leftmost 21 bits */
#define e_rsel4/* R’: rightmost 11 bits */
#define e_ldsel5/* LD’: inverse of RD’ */
#define e_rdsel6/* RD’: rightmost 11 bits, filled left with ones */
#define e_lrsel7/* LR’: L’ with "rounded" constant */
#define e_rrsel8/* RR’: R’ with "rounded" constant */

/* Values for fixup_format (typical instructions shown) */
#define i_exp140/* 14-bit immediate (LDW, STW) */
#define i_exp211/* 21-bit immediate (LDIL, ADDIL) */
#define i_exp112/* 11-bit immediate (ADDI, SUBI) */
#define i_rel173/* 17-bit pc-relative (BL) */
#define i_rel124/* 12 bit pc-relative (COMBT, COMBF, etc.) */
#define i_data5/* whole word */
#define i_none6/* not used */
#define i_abs177/* 17-bit absolute (BE, BLE) */
#define i_milli8/* 17-bit millicode call (BLE) */
#define i_break9/* reserved (no effect on HP-UX) */

In newer object files, relocation entries consist of a stream of bytes. The fixup_request_index field in the subspace dictionary entry is a byte offset into the fixup dictionary defined by the file header, and the fixup_request_quantity field defines the length of the fixup request stream, in bytes, for that subspace. The first byte of each fixup request (the opcode) identifies the request and determines the length of the request.

In general, the fixup stream is a series of linker instructions that governs how the linker places data in the a.out file. Certain fixup requests cause the linker to copy one or more bytes from the input subspace to the output subspace without change, while others direct the linker to relocate words or resolve external references. Still others direct the linker to insert zeroes in the output subspace or to leave areas uninitialized without copying any data from the input subspace, and others describe points in the code without contributing any new data to the output file.

The include file <reloc.h> defines constants for each major opcode. Many fixup requests use a range of opcodes; only a constant for the beginning of the range is defined. The meaning of each fixup request is described below. The opcode ranges and parameters for each fixup are described in the table further below.

R_NO_RELOCATION Copy L bytes with no relocation.

R_ZEROES Insert L zero bytes into the output subspace.

R_UNINIT Skip L bytes in the output subspace.

R_RELOCATION Copy one data word with relocation. The word is assumed to contain a 32-bit pointer relative to its own subspace.

R_DATA_ONE_SYMBOL
Copy one data word with relocation relative to an external symbol whose symbol index is S.

R_DATA_PLABEL Copy one data word as a 32-bit procedure label, referring to the symbol S. The original contents of the word should be 0 (no static link) or 2 (static link required).

R_SPACE_REF Copy one data word as a space reference. This fixup request is not currently supported.

R_REPEATED_INIT Copy L bytes from the input subspace, replicating the data to fill M bytes in the output subspace.

R_PCREL_CALL Copy one instruction word with relocation. The word is assumed to be a pc-relative procedure call instruction (for example, BL). The target procedure is identified by symbol S, and the parameter relocation bits are R.

R_ABS_CALL Copy one instruction word with relocation. The word is assumed to be an absolute procedure call instruction (for example, BLE). The target procedure is identified by symbol S, and the parameter relocation bits are R.

R_DP_RELATIVE Copy one instruction word with relocation. The word is assumed to be a dp-relative load or store instruction (for example, ADDIL, LDW, STW). The target symbol is identified by symbol S. The linker forms the difference between the value of the symbol S and the value of the symbol $global$. By convention, the value of $global$ is always contained in register 27. Instructions other than LDIL and ADDIL may have a small constant in the displacement field of the instruction.

R_DLT_REL Copy one instruction word with relocation. The word is assumed to be a register r18-relative load or store instruction (for example, LDW, LDO, STW). The target symbol is identified by symbol S. The linker computes a linkage table offset relative to register 18 (reserved for a linkage table pointer in position-independent-code) for the symbol S.

R_CODE_ONE_SYMBOL
Copy one instruction word with relocation. The word is assumed to be an instruction referring to symbol S (for example, LDIL, LDW, BE). Instructions other than LDIL and ADDIL may have a small constant in the displacement field of the instruction.

R_MILLI_REL Copy one instruction word with relocation. The word is assumed to be a short millicode call instruction (for example, BLE). The linker forms the difference between the value of the target symbol S and the value of symbol 1 in the module’s symbol table. By convention, the value of symbol 1 should have been previously loaded into the base register used in the BLE instruction. The instruction may have a small constant in the displacement field of the instruction.

R_CODE_PLABEL Copy one instruction word with relocation. The word is assumed to be part of a code sequence forming a procedure label (for example, LDIL, LDO), referring to symbol S. The LDO instruction should contain the value 0 (no static link) or 2 (static link required) in its displacement field.

R_BREAKPOINT Copy one instruction word conditionally. On HP-UX, the linker always replaces the word with a NOP instruction.

R_ENTRY Define a procedure entry point. The stack unwind bits, U, and the frame size, F, are recorded in a stack unwind descriptor.

R_ALT_ENTRY Define an alternate procedure entry point.

R_EXIT Define a procedure exit point.

R_BEGIN_TRY Define the beginning of a try/recover region.

R_END_TRY Define the end of a try/recover region. The offset R defines the distance in bytes from the end of the region to the beginning of the recover block.

R_BEGIN_BRTAB Define the beginning of a branch table.

R_END_BRTAB Define the end of a branch table.

R_AUX_UNWIND Define an auxiliary unwind table. CN is a symbol index of the symbol that labels the beginning of the compilation unit string table. SN is the offset, relative to the CN symbol, of the scope name string. SK is an integer specifying the scope kind.

R_STATEMENT Define the beginning of statement number N.

R_SEC_STATEMENT Define the beginning of a secondary statement number N.

R_DATA_EXPR Pop one word from the expression stack and copy one data word from the input subspace to the output subspace, adding the popped value to it.

R_CODE_EXPR Pop one word from the expression stack, and copy one instruction word from the input subspace to the output subspace, adding the popped value to the displacement field of the instruction.

R_FSEL Use an F′ field selector for the next fixup request instead of the default appropriate for the instruction.

R_LSEL Use an L-class field selector for the next fixup request instead of the default appropriate for the instruction. Depending on the current rounding mode, L′, LS′, LD′, or LR′ may be used.

R_RSEL Use an R-class field selector for the next fixup request instead of the default appropriate for the instruction. Depending on the current rounding mode, R′, RS′, RD′, or RR′ may be used.

R_N_MODE Select round-down mode (L′/R′). This is the default mode at the beginning of each subspace. This setting remains in effect until explicitly changed or until the end of the subspace.

R_S_MODE Select round-to-nearest-page mode (LS′/RS′). This setting remains in effect until explicitly changed or until the end of the subspace.

R_D_MODE Select round-up mode (LD′/RD′). This setting remains in effect until explicitly changed or until the end of the subspace.

R_R_MODE Select round-down-with-adjusted-constant mode (LR′/RR′). This setting remains in effect until explicitly changed or until the end of the subspace.

R_DATA_OVERRIDE Use the constant V for the next fixup request in place of the constant from the data word or instruction in the input subspace.

R_TRANSLATED Toggle “translated” mode. This fixup request is generated only by the linker during a relocatable link to indicate a subspace that was originally read from an old-format relocatable object file.

R_COMP1 Stack operations. The second byte of this fixup request contains a secondary opcode. In the descriptions below, A refers to the top of the stack and B refers to the next item on the stack. All items on the stack are considered signed 32-bit integers.

R_PUSH_PCON1 Push the (positive) constant V.

R_PUSH_DOT Push the current virtual address.

R_MAX Pop A and B, then push max(A, B).

R_MIN Pop A and B, then push min(A, B).

R_ADD Pop A and B, then push A + B.

R_SUB Pop A and B, then push B - A.

R_MULT Pop A and B, then push A * B.

R_DIV Pop A and B, then push B / A.

R_MOD Pop A and B, then push B % A.

R_AND Pop A and B, then push A & B.

R_OR Pop A and B, then push A | B.

R_XOR Pop A and B, then push A XOR B.

R_NOT Replace A with its complement.

R_LSHIFT If C = 0, pop A and B, then push B << A. Otherwise, replace A with A << C.

R_ARITH_RSHIFT If C = 0, pop A and B, then push B >> A. Otherwise, replace A with A >> C. The shifting is done with sign extension.

R_LOGIC_RSHIFT If C = 0, pop A and B, then push B >> A. Otherwise, replace A with A >> C. The shifting is done with zero fill.

R_PUSH_NCON1 Push the (negative) constant V.

R_COMP2 More stack operations.

R_PUSH_PCON2 Push the (positive) constant V.

R_PUSH_SYM Push the value of the symbol S.

R_PUSH_PLABEL Push the value of a procedure label for symbol S. The static link bit is L.

R_PUSH_NCON2 Push the (negative) constant V.

R_COMP3 More stack operations.

R_PUSH_PROC Push the value of the procedure entry point S. The parameter relocation bits are R.

R_PUSH_CONST Push the constant V.

R_PREV_FIXUP The linker keeps a queue of the last four unique multi-byte fixup requests; this is an abbreviation for a fixup request identical to one on the queue. The queue index X references one of the four; X = 0 refers to the most recent. As a side effect of this fixup request, the referenced fixup is moved to the front of the queue.

R_RESERVED Fixups in this range are reserved for internal use by the compilers and linker.

The following table shows the mnemonic fixup request type and length and parameter information for each range of opcodes. In the parameters column, the symbol D refers to the difference between the opcode and the beginning of the range described by that table entry; the symbols B1, B2, B3, and B4 refer to the value of the next one, two, three, or four bytes of the fixup request, respectively.

mnemonic	opcodes	length	parameters
R_NO_RELOCATION	0-23	1	L = (D+1) * 4
	24-27	2	L = (D<<8 + B1 + 1) * 4
	28-30	3	L = (D<<16 + B2 + 1) * 4
	31	4	L = B3 + 1
R_ZEROES	32	2	L = (B1 + 1) * 4
	33	4	L = B3 + 1
R_UNINIT	34	2	L = (B1 + 1) * 4
	35	4	L = B3 + 1
R_RELOCATION	36	1	none
R_DATA_ONE_SYMBOL	37	2	S = B1
	38	4	S = B3
R_DATA_PLABEL	39	2	S = B1
	40	4	S = B3
R_SPACE_REF	41	1	none
R_REPEATED_INIT	42	2	L = 4; M = (B1 + 1) * 4
	43	3	L = B1 * 4; M = (B1 + 1) * L
	44	5	L = B1 * 4; M = (B3 + 1) * 4
	45	8	L = B3 + 1; M = B4 + 1
R_PCREL_CALL	48−57	2	R = rbits1(D); S = B1
	58−59	3	R = rbits2(D<<8 + B1); S = B1
	60−61	5	R = rbits2(D<<8 + B1); S = B3
R_ABS_CALL	64−73	2	R = rbits1(D); S = B1
	74−75	3	R = rbits2(D<<8 + B1); S = B1
	76−77	5	R = rbits2(D<<8 + B1); S = B3
R_DP_RELATIVE	80−111	1	S = D
	112	2	S = B1
	113	4	S = B3
R_DLT_REL	120	2	S = B1
	121	4	S = B3
R_CODE_ONE_SYMBOL	128−159	1	S = D
	160	2	S = B1
	161	2	S = B3
R_MILLI_REL	174	2	S = B1
	175	4	S = B3
R_CODE_PLABEL	176	2	S = B1
	177	4	S = B3
R_BREAKPOINT	178	1	none
R_ENTRY	179	9	U,F = B8 (U is 37 bits; F is 27 bits)
	180	6	U = B5 >> 3; F = pop A
R_ALT_ENTRY	181	1	none
R_EXIT	182	1	none
R_BEGIN_TRY	183	1	none
R_END_TRY	184	1	R = 0
	185	2	R = B1 * 4
	186	4	R = B3 * 4
R_BEGIN_BRTAB	187	1	none
R_END_BRTAB	188	1	none
R_STATEMENT	189	2	N = B1
	190	3	N = B2
	191	4	N = B3
R_DATA_EXPR	192	1	none
R_CODE_EXPR	193	1	none
R_FSEL	194	1	none
R_LSEL	195	1	none
R_RSEL	196	1	none
R_N_MODE	197	1	none
R_S_MODE	198	1	none
R_D_MODE	199	1	none
R_R_MODE	200	1	none
R_DATA_OVERRIDE	201	1	V = 0
	202	2	V = B1
	203	3	V = B2
	204	4	V = B3
	205	5	V = B4
R_TRANSLATED	206	1	none
R_AUX_UNWIND	207	12	CU,SN,SK = B11 (CU is 24 bits; SN is 32 bits; SK is 32 bits)
R_COMP1	208	2	OP = B1; V = OP & 0x3f; C = OP & 0x1f
R_COMP2	209	5	OP = B1; S = B3; L = OP & 1;
			V = ((OP & 0x7f) << 24) \| S
R_COMP3	210	6	OP = B1; V = B4;
			R = ((OP & 1) << 8) \| (V >> 16);
			S = V & 0xffffff
R_PREV_FIXUP	211−214	1	X = D
R_SEC_STMT	215	1	none
R_RESERVED	224−255	\-	reserved

Parameter relocation bits are encoded in the fixup requests in two ways, noted as rbits1 and rbits2 in the above table. The first encoding recognizes that the most common procedure calls have only general register arguments with no holes in the parameter list. The encoding for such calls is simply the number of parameters in general registers (0 to 4), plus 5 if there is a return value in a general register.

The second encoding is more complex; the 10 argument relocation bits are compressed into 9 bits by eliminating some impossible combinations. The encoding is the combination of three contributions. The first contribution is the pair of bits for the return value, which are not modified. The second contribution is 9 if the first two parameter words together form a double-precision parameter; otherwise, it is 3 times the pair of bits for the first word plus the pair of bits for the second word. Similarly, the third contribution is formed based on the third and fourth parameter words. The second contribution is multiplied by 40, the third is multiplied by 4, then the three are added together.

Compiler Records

Compiler records are placed in relocatable files by each compiler or assembler to identify the version of the compiler that was used to produce the file. These records are copied into the executable file by the linker, but are strippable. The structure of a compiler record is shown below. All strings are contained in the symbol string table.

struct compilation_unit {
union name_ptname;
union name_ptlanguage_name;
union name_ptproduct_id;
union name_ptversion_id;
intreserved;
struct sys_clock compile_time;
struct sys_clock source_time;
};

Museum

Related Articles