1585 lines
58 KiB
Plaintext
1585 lines
58 KiB
Plaintext
|
|
|
|
|
|
a.out(4) Architecture-Dependent File Format a.out(4)
|
|
|
|
|
|
|
|
|
|
NAME
|
|
a.out - assembler and link editor output
|
|
|
|
REMARKS
|
|
A separate manual entry describes each implementation of the a.out
|
|
file format for Series 300/400 and Series 700/800 systems.
|
|
|
|
DESCRIPTION
|
|
The a.out (i.e., object file) format is completely machine-dependent
|
|
except for the first word, which contains a magic number as defined in
|
|
magic(4).
|
|
|
|
The archive symbol table format is also completely machine-dependent
|
|
except for its name in the archive. See ar(4) for a description of
|
|
the format of the archive symbol table.
|
|
|
|
SEE ALSO
|
|
crt0(3), end(3C), a.out_300(4), a.out_800(4), ar(4), magic(4).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Hewlett-Packard Company - 1 - HP-UX Release 9.0: August 1992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a.out_300(4) Series 300/400 Implementation a.out_300(4)
|
|
|
|
|
|
|
|
|
|
NAME
|
|
a.out - assembler and link editor output
|
|
|
|
Remarks:
|
|
This manual entry describes the a.out file format for Series 300/400
|
|
computers. Refer to other a.out*(4) manual entries for descriptions
|
|
of other implementations.
|
|
|
|
DESCRIPTION
|
|
The a.out file is the output file of the link editor ld (see ld(1).
|
|
The linker makes a.out executable if there were no linking errors and
|
|
no unresolved external references. The assembler as (or ld with the
|
|
-r option) produces non-executable files with the same basic
|
|
structure.
|
|
|
|
File a.out has eight defined sections: a header, the program text and
|
|
data segments, a Pascal interface section, a symbol table, a
|
|
supplementary symbol table, and text and data relocation information
|
|
(in that order). Pascal interface text will only be present in those
|
|
Pascal code segments that have not been linked. The symbol table may
|
|
be missing if the program was linked with the ld -s option, or if the
|
|
symbol table and debug information were removed by strip (see
|
|
strip(1)). The supplementary symbol table is present only in files
|
|
containing position-independent code, or in files that were produced
|
|
with the Pascal compiler or the +s option to the assembler. Also note
|
|
that relocation information is not normally present in executable
|
|
files.
|
|
|
|
In addition to these sections, there may be one or more extensions.
|
|
Each extension is preceded by a header consisting of an extension-
|
|
independent part and an extension-dependent part. Currently defined
|
|
extensions include one for dynamic loading support and one for
|
|
debugger support. The dynamic loader extension is actually placed
|
|
within the text segment of shared library files (created with the -b
|
|
option to ld) and executables that use shared libraries. The debugger
|
|
extension is placed after the relocation sections. HP-UX compilers
|
|
create this information under control of the -g option.
|
|
|
|
When an a.out file is loaded into memory for execution, three logical
|
|
segments are set up: the text segment, the data segment (initialized
|
|
data followed by uninitialized, the latter actually being initialized
|
|
to all 0's), and a stack. The text segment begins at location 0x0 in
|
|
the core image; the header is not loaded. If the magic number (the
|
|
first field in the header) is EXEC_MAGIC, it indicates that the text
|
|
segment is not to be write-protected or shared, so the data segment
|
|
will be contiguous with the text segment. If the magic number is
|
|
SHARE_MAGIC or DEMAND_MAGIC, the data segment begins at the first 0
|
|
mod 0x1000 byte boundary following the text segment, and the text
|
|
segment is not writable by the program; if other processes are
|
|
executing the same a.out file, they will share a single text segment.
|
|
If the magic number is DEMAND_MAGIC, the text and data segments are
|
|
|
|
|
|
|
|
Hewlett-Packard Company - 1 - HP-UX Release 9.0: August 1992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a.out_300(4) Series 300/400 Implementation a.out_300(4)
|
|
|
|
|
|
|
|
|
|
not read in from the file until they are referenced by the program.
|
|
|
|
The stack will occupy the highest possible locations in the core image
|
|
and grow downward (the stack is automatically extended as required).
|
|
The data segment is only extended as requested by the brk() system
|
|
call (see brk(2)).
|
|
|
|
Shared libraries, indicated by the magic number SHL_MAGIC, are similar
|
|
to demand-loaded executables, except that they are loaded by the
|
|
dynamic loader /lib/dld.sl (see dld.sl(5)) at some point during
|
|
startup, rather than by exec(), and that the load address is
|
|
arbitrary. No stack segment is set up for shared libraries; they
|
|
share the stack used by the executable. The data and bss segments of
|
|
a shared library are shared on a page by page basis by all processes
|
|
using the library. Whenever a process writes to a shared library data
|
|
or bss segment, a modified copy of that page is made for the process.
|
|
Dynamic load libraries, indicated by the magic number DL_MAGIC, are
|
|
analagous to shared libraries except that the text segment is also
|
|
made copy on write in order to support dynamic relocation.
|
|
|
|
The start of the text segment in the a.out file is given by the macro
|
|
TEXT_OFFSET(hdr), where hdr is a copy of the file header. The macro
|
|
DATA_OFFSET(hdr) provides the starting location of the data segment.
|
|
|
|
The value of a word in the text or data portions that is not a
|
|
reference to an undefined external symbol is exactly the value that
|
|
will appear in memory when the file is executed. If a word in the
|
|
text or data portion involves a reference to an undefined external
|
|
symbol, as indicated by the relocation information (discussed below)
|
|
for that word, then the value of the word as stored in the file is an
|
|
offset from the associated external symbol. When the file is
|
|
processed by the link editor and the external symbol becomes defined,
|
|
the value of the symbol will be added to the word in the file.
|
|
|
|
Header
|
|
The format of the a.out header for the MC68000 is as follows (segment
|
|
sizes are in bytes):
|
|
|
|
struct exec {
|
|
MAGIC a_magic; /* magic number */
|
|
short a_stamp; /* version id */
|
|
short a_highwater; /* shlib highwater mark */
|
|
long a_miscinfo; /* miscellaneous info */
|
|
long a_text; /* size of text segment */
|
|
long a_data; /* size of data segment */
|
|
long a_bss; /* size of bss segment */
|
|
long a_trsize; /* text relocation size */
|
|
long a_drsize; /* data relocation size */
|
|
long a_pasint; /* Pascal interface size */
|
|
long a_lesyms; /* symbol table size */
|
|
long a_spared;
|
|
|
|
|
|
|
|
Hewlett-Packard Company - 2 - HP-UX Release 9.0: August 1992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a.out_300(4) Series 300/400 Implementation a.out_300(4)
|
|
|
|
|
|
|
|
|
|
long a_entry; /* entry point */
|
|
long a_spares;
|
|
long a_supsym; /* supplementary symtab size */
|
|
long a_drelocs; /* nonpic relocations */
|
|
long a_extension; /* file offset of extension */
|
|
};
|
|
|
|
Pascal Interface Section
|
|
The Pascal interface section consists of the ASCII representation of
|
|
the interface text for that Pascal module.
|
|
|
|
The start of the Pascal interface section is given by the macro
|
|
MODCAL_OFFSET(hdr).
|
|
|
|
Symbol Table
|
|
The symbol table consists of entries of the form:
|
|
|
|
struct nlist {
|
|
long n_value;
|
|
unsigned char n_type;
|
|
unsigned char n_length;
|
|
short n_almod;
|
|
int n_dlt:1;
|
|
int n_plt:1;
|
|
int n_dreloc:1;
|
|
int n_list:1;
|
|
int n_unused:12;
|
|
};
|
|
|
|
This structure is followed by n_length ASCII characters which compose
|
|
the symbol name.
|
|
|
|
The n_type field indicates the type of the symbol; the following
|
|
values are possible:
|
|
|
|
UNDEF undefined symbol
|
|
ABS absolute symbol
|
|
TEXT text segment symbol
|
|
DATA data segment symbol
|
|
BSS bss segment symbol
|
|
|
|
One of these values ORed with 040 indicates an external symbol. One
|
|
of these values ORed with 020 indicates an aligned symbol. One of
|
|
these values ORed with 0100 indicates a secondary definition.
|
|
|
|
The bit fields are used by the linker for the relocation of position-
|
|
independent code (generated with the +z option to the compilers) when
|
|
creating a shared library.
|
|
|
|
The start of the symbol table is given by the macro LESYM_OFFSET(hdr).
|
|
|
|
|
|
|
|
|
|
Hewlett-Packard Company - 3 - HP-UX Release 9.0: August 1992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a.out_300(4) Series 300/400 Implementation a.out_300(4)
|
|
|
|
|
|
|
|
|
|
In object files that were compiled as position-independent code,
|
|
generated by the Pascal compiler, or assembled with the as +s option,
|
|
a supplementary symbol table follows the standard symbol table. This
|
|
table is a simple array of eight-byte structures which stand in one-
|
|
to-one correspondence with the symbol table entries. The fields of
|
|
this structure are used by the linker when creating a shared library.
|
|
|
|
Relocation
|
|
If relocation information is present, it amounts to eight bytes per
|
|
relocatable datum.
|
|
|
|
The format of the relocation data is:
|
|
|
|
struct r_info {
|
|
long r_address;
|
|
short r_symbolnum;
|
|
char r_segment;
|
|
char r_length;
|
|
};
|
|
|
|
The r_address field indicates the position of the relocation within
|
|
the segment.
|
|
|
|
The r_segment field indicates the segment referred to by the text or
|
|
data word associated with the relocation word:
|
|
|
|
RTEXT indicates the reference is to the text segment;
|
|
RDATA indicates the reference is to initialized data;
|
|
RBSS indicates the reference is to bss (uninitialized data);
|
|
REXT indicates the reference is to an undefined external
|
|
symbol;
|
|
RPC indicates the reference is PC relative;
|
|
RDLT indicates the reference is to an offset from the base
|
|
of the data linkage table;
|
|
RPLT indicates the reference is to an entry within the
|
|
procedure linkage table.
|
|
|
|
The latter three relocation types are found primarily in position-
|
|
independent code.
|
|
|
|
The r_symbolnum field contains a symbol number in the case of external
|
|
references, and is unused otherwise. The first symbol is numbered 0,
|
|
the second 1, etc.
|
|
|
|
The r_length field indicates the length of the datum to be relocated.
|
|
|
|
RBYTE indicates it is a byte
|
|
RWORD indicates it is a short
|
|
RLONG indicates it is a long
|
|
RALIGN indicates it is a special align symbol
|
|
|
|
|
|
|
|
|
|
Hewlett-Packard Company - 4 - HP-UX Release 9.0: August 1992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a.out_300(4) Series 300/400 Implementation a.out_300(4)
|
|
|
|
|
|
|
|
|
|
The start of the text relocation section is provided by the macro
|
|
RTEXT_OFFSET(hdr).
|
|
|
|
The start of the data relocation section is provided by the macro
|
|
RDATA_OFFSET(hdr).
|
|
|
|
Extensions
|
|
The a_extension field of the header gives the file offset of the first
|
|
extension, and each extension header gives the file offset of the
|
|
next. The dynamic loader extension, if present, will be the first
|
|
extension present, and the debugger extension, if present, will be
|
|
next. Additional extensions can be defined by certain languages or
|
|
tools. When present, they are placed after the dynamic loader and
|
|
debugger extensions.
|
|
|
|
The extension header is of the form
|
|
|
|
struct header_extension
|
|
{
|
|
union
|
|
{
|
|
long spare1[13];
|
|
struct _dl_header dl_header;
|
|
struct _debug_header debug_header;
|
|
} e_spec;
|
|
short e_header;
|
|
short e_version;
|
|
long e_size;
|
|
long e_extension;
|
|
};
|
|
|
|
The union allows for extension specific information to be included in
|
|
the header. The e_header field contains a constant which identifies
|
|
the extension type. Currently defined values include DL_HEADER and
|
|
DEBUG_HEADER. The e_version field can be used to identify different
|
|
versions of an extension. The e_size field gives the collective size
|
|
for the extension; e_extension gives the file offset of the next
|
|
extension.
|
|
|
|
For more information about the dynamic loader extension and the debug
|
|
extension, consult the files /usr/include/shl.h and
|
|
/usr/include/debug.h, respectively.
|
|
|
|
SEE ALSO
|
|
as_300(1), ld(1), nm_300(1), strip(1), crt0(3), end(3C), a.out_800(4),
|
|
magic(4).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Hewlett-Packard Company - 5 - HP-UX Release 9.0: August 1992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a.out_800(4) Series 700/800 Implementation a.out_800(4)
|
|
|
|
|
|
|
|
|
|
NAME
|
|
a.out - assembler and link editor output
|
|
|
|
SYNOPSIS
|
|
#include <a.out.h>
|
|
|
|
Remarks:
|
|
This manual entry 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 (see as(1)),
|
|
compilers, and the linker (see 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.
|
|
|
|
|
|
|
|
Hewlett-Packard Company - 1 - HP-UX Release 9.0: August 1992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a.out_800(4) Series 700/800 Implementation a.out_800(4)
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
Hewlett-Packard Company - 2 - HP-UX Release 9.0: August 1992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a.out_800(4) Series 700/800 Implementation a.out_800(4)
|
|
|
|
|
|
|
|
|
|
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 */
|
|
|
|
|
|
|
|
Hewlett-Packard Company - 3 - HP-UX Release 9.0: August 1992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a.out_800(4) Series 700/800 Implementation a.out_800(4)
|
|
|
|
|
|
|
|
|
|
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 int mandatory : 1; /* reserved */
|
|
unsigned int copy : 1; /* reserved */
|
|
unsigned int append : 1; /* reserved */
|
|
unsigned int ignore : 1; /* reserved */
|
|
unsigned int reserved : 12; /* reserved */
|
|
unsigned int type : 16; /* aux hdr type */
|
|
unsigned int length; /* sizeof rest of aux hdr */
|
|
};
|
|
|
|
/* Values for the aux_id.type field */
|
|
#define HPUX_AUX_ID 4
|
|
#define VERSION_AUX_ID 6
|
|
#define COPYRIGHT_AUX_ID 9
|
|
#define SHLIB_VERSION_AUX_ID 10
|
|
|
|
struct som_exec_auxhdr { /* HP-UX auxiliary header */
|
|
struct aux_id som_auxhdr; /* aux header id */
|
|
long exec_tsize; /* text size */
|
|
long exec_tmem; /* start address of text */
|
|
|
|
|
|
|
|
Hewlett-Packard Company - 4 - HP-UX Release 9.0: August 1992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a.out_800(4) Series 700/800 Implementation a.out_800(4)
|
|
|
|
|
|
|
|
|
|
long exec_tfile; /* file ptr to text */
|
|
long exec_dsize; /* data size */
|
|
long exec_dmem; /* start address of data */
|
|
long exec_dfile; /* file ptr to data */
|
|
long exec_bsize; /* bss size */
|
|
long exec_entry; /* address of entry point */
|
|
long exec_flags; /* loader flags */
|
|
long exec_bfill; /* bss initialization value */
|
|
};
|
|
|
|
/* Values for exec_flags */
|
|
#define TRAP_NIL_PTRS 01
|
|
|
|
struct user_string_aux_hdr { /* Version string auxiliary header */
|
|
struct aux_id header_id; /* aux header id */
|
|
unsigned int string_length; /* strlen(user_string) */
|
|
char user_string[1]; /* user-defined string */
|
|
};
|
|
|
|
struct copyright_aux_hdr { /* Copyright string auxiliary header */
|
|
struct aux_id header_id; /* aux header id */
|
|
unsigned int string_length; /* strlen(user_string) */
|
|
char copyright[1]; /* user-defined string */
|
|
};
|
|
struct shlib_version_aux_hdr {
|
|
struct aux_id header_id; /* aux header id */
|
|
short version; /* 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_pt name; /* index to space name */
|
|
unsigned int is_loadable: 1; /* space is loadable */
|
|
unsigned int is_defined: 1; /* space is defined within file */
|
|
unsigned int is_private: 1; /* space is not sharable */
|
|
unsigned int reserved: 13; /* reserved */
|
|
unsigned int sort_key: 8; /* sort key for space */
|
|
unsigned int reserved2: 8; /* reserved */
|
|
int space_number; /* space index */
|
|
int subspace_index; /* index to first subspace */
|
|
unsigned int subspace_quantity; /* # of subspaces in space */
|
|
int loader_fix_index; /* reserved */
|
|
unsigned int loader_fix_quantity; /* reserved */
|
|
int init_pointer_index; /* reserved */
|
|
unsigned int init_pointer_quantity; /* reserved */
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
Hewlett-Packard Company - 5 - HP-UX Release 9.0: August 1992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a.out_800(4) Series 700/800 Implementation a.out_800(4)
|
|
|
|
|
|
|
|
|
|
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 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 int n_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 {
|
|
int space_index;
|
|
unsigned int access_control_bits: 7; /* reserved */
|
|
unsigned int memory_resident: 1; /* reserved */
|
|
unsigned int dup_common: 1; /* COBOL-style common */
|
|
unsigned int is_common: 1; /* subspace is a common block */
|
|
unsigned int is_loadable: 1; /* subspace is loadable */
|
|
unsigned int quadrant: 2; /* reserved */
|
|
unsigned int initially_frozen: 1; /* reserved */
|
|
unsigned int is_first: 1; /* reserved */
|
|
unsigned int code_only: 1; /* subspace contains only code */
|
|
unsigned int sort_key: 8; /* subspace sort key */
|
|
unsigned int replicate_init: 1; /* reserved */
|
|
unsigned int continuation: 1; /* reserved */
|
|
unsigned int reserved: 6; /* reserved */
|
|
int file_loc_init_value; /* file location or init value */
|
|
unsigned int initialization_length; /* length of initialization */
|
|
unsigned int subspace_start; /* starting offset */
|
|
unsigned int subspace_length; /* total subspace length */
|
|
unsigned int reserved2: 16; /* reserved */
|
|
unsigned int alignment: 16; /* alignment required */
|
|
union name_pt name; /* index of subspace name */
|
|
int fixup_request_index; /* index to first fixup */
|
|
unsigned int fixup_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
|
|
|
|
|
|
|
|
Hewlett-Packard Company - 6 - HP-UX Release 9.0: August 1992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a.out_800(4) Series 700/800 Implementation a.out_800(4)
|
|
|
|
|
|
|
|
|
|
structure is identical with the space strings table.
|
|
|
|
struct symbol_dictionary_record {
|
|
unsigned int hidden: 1; /* reserved */
|
|
unsigned int symbol_type: 7; /* symbol type */
|
|
unsigned int symbol_scope: 4; /* symbol value */
|
|
unsigned int check_level: 3; /* type checking level */
|
|
unsigned int must_qualify: 1; /* qualifier required */
|
|
unsigned int initially_frozen: 1; /* reserved */
|
|
unsigned int memory_resident: 1; /* reserved */
|
|
unsigned int is_common: 1; /* common block */
|
|
unsigned int dup_common: 1; /* COBOL-style common */
|
|
unsigned int xleast: 2; /* reserved */
|
|
unsigned int arg_reloc: 10; /* parameter relocation bits */
|
|
union name_pt name; /* index to symbol name */
|
|
union name_pt qualifier_name; /* index to qual name */
|
|
unsigned int symbol_info; /* subspace index */
|
|
unsigned int symbol_value; /* symbol value */
|
|
};
|
|
|
|
/* Values for symbol_type */
|
|
#define ST_NULL 0 /* unused symbol entry */
|
|
#define ST_ABSOLUTE 1 /* non-relocatable symbol */
|
|
#define ST_DATA 2 /* data symbol */
|
|
#define ST_CODE 3 /* generic code symbol */
|
|
#define ST_PRI_PROG 4 /* program entry point */
|
|
#define ST_SEC_PROG 5 /* secondary prog entry point*/
|
|
#define ST_ENTRY 6 /* procedure entry point */
|
|
#define ST_STORAGE 7 /* storage request */
|
|
#define ST_STUB 8 /* reserved */
|
|
#define ST_MODULE 9 /* Pascal module name */
|
|
#define ST_SYM_EXT 10 /* symbol extension record */
|
|
#define ST_ARG_EXT 11 /* argument extension record */
|
|
#define ST_MILLICODE 12 /* millicode entry point */
|
|
#define ST_PLABEL 13 /* reserved */
|
|
#define ST_OCT_DIS 14 /* reserved */
|
|
#define ST_MILLI_EXT 15 /* reserved */
|
|
|
|
/* Values for symbol_scope */
|
|
#define SS_UNSAT 0 /* unsatisfied reference */
|
|
#define SS_EXTERNAL 1 /* reserved */
|
|
#define SS_LOCAL 2 /* local symbol */
|
|
#define SS_UNIVERSAL 3 /* 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
|
|
|
|
|
|
|
|
Hewlett-Packard Company - 7 - HP-UX Release 9.0: August 1992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a.out_800(4) Series 700/800 Implementation a.out_800(4)
|
|
|
|
|
|
|
|
|
|
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 int reserved: 3; /* not used */
|
|
unsigned int packing: 1; /* reserved */
|
|
unsigned int alignment: 4; /* byte alignment */
|
|
unsigned int reserved2: 1; /* not used */
|
|
unsigned int mode: 3; /* use of symbol */
|
|
unsigned int structure: 4; /* structure of symbol */
|
|
unsigned int hash: 1; /* set if arg_type is hashed */
|
|
int arg_type: 15; /* data type */
|
|
} arg_desc;
|
|
unsigned int word;
|
|
};
|
|
|
|
struct symbol_extension_record {
|
|
unsigned int type: 8; /* always ST_SYM_EXT */
|
|
unsigned int max_num_args: 8; /* max # of parameters */
|
|
unsigned int min_num_args: 8; /* min # of parameters */
|
|
unsigned int num_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 int type: 8; /* always ST_ARG_EXT */
|
|
unsigned int reserved: 24; /* not used */
|
|
union arg_descriptor argument_desc[4]; /* next 4 parameters */
|
|
};
|
|
|
|
|
|
|
|
|
|
Hewlett-Packard Company - 8 - HP-UX Release 9.0: August 1992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a.out_800(4) Series 700/800 Implementation a.out_800(4)
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
Hewlett-Packard Company - 9 - HP-UX Release 9.0: August 1992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a.out_800(4) Series 700/800 Implementation a.out_800(4)
|
|
|
|
|
|
|
|
|
|
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 systems each fixup request is a five-word
|
|
structure describing 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 int need_data_ref: 1; /* reserved */
|
|
unsigned int arg_reloc: 10; /* parameter relocation bits */
|
|
unsigned int expression_type: 5; /* how to compute value */
|
|
unsigned int exec_level: 2; /* reserved */
|
|
unsigned int fixup_format: 6; /* how to deposit bits */
|
|
unsigned int fixup_field: 8; /* field to extract */
|
|
unsigned int subspace_offset; /* subspace offset of word */
|
|
unsigned int symbol_index_one; /* index of first symbol */
|
|
unsigned int symbol_index_two; /* index of second symbol */
|
|
int fixup_constant; /* constant */
|
|
};
|
|
|
|
/* Values for expression_type */
|
|
#define e_one 0 /* symbol1 + constant */
|
|
#define e_two 1 /* symbol1 - symbol2 + constant */
|
|
#define e_pcrel 2 /* symbol1 - pc + constant */
|
|
#define e_con 3 /* constant */
|
|
#define e_plabel 7 /* symbol1 + constant */
|
|
#define e_abs 18 /* reserved */
|
|
|
|
|
|
|
|
|
|
|
|
Hewlett-Packard Company - 10 - HP-UX Release 9.0: August 1992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a.out_800(4) Series 700/800 Implementation a.out_800(4)
|
|
|
|
|
|
|
|
|
|
/* Values for fixup_field (assembler mnemonics shown) */
|
|
#define e_fsel 0 /* F': no change */
|
|
#define e_lssel 1 /* LS': inverse of RS' */
|
|
#define e_rssel 2 /* RS': rightmost 11 bits, signed */
|
|
#define e_lsel 3 /* L': leftmost 21 bits */
|
|
#define e_rsel 4 /* R': rightmost 11 bits */
|
|
#define e_ldsel 5 /* LD': inverse of RD' */
|
|
#define e_rdsel 6 /* RD': rightmost 11 bits, filled left with ones */
|
|
#define e_lrsel 7 /* LR': L' with rounded" constant */"
|
|
#define e_rrsel 8 /* RR': R' with rounded" constant */"
|
|
|
|
/* Values for fixup_format (typical instructions shown) */"
|
|
#define i_exp14 0 /* 14-bit immediate (LDW, STW) */
|
|
#define i_exp21 1 /* 21-bit immediate (LDIL, ADDIL) */
|
|
#define i_exp11 2 /* 11-bit immediate (ADDI, SUBI) */
|
|
#define i_rel17 3 /* 17-bit pc-relative (BL) */
|
|
#define i_rel12 4 /* 12 bit pc-relative (COMBT, COMBF, etc.) */
|
|
#define i_data 5 /* whole word */
|
|
#define i_none 6 /* not used */
|
|
#define i_abs17 7 /* 17-bit absolute (BE, BLE) */
|
|
#define i_milli 8 /* 17-bit millicode call (BLE) */
|
|
#define i_break 9 /* 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.
|
|
|
|
|
|
|
|
|
|
|
|
Hewlett-Packard Company - 11 - HP-UX Release 9.0: August 1992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a.out_800(4) Series 700/800 Implementation a.out_800(4)
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
Hewlett-Packard Company - 12 - HP-UX Release 9.0: August 1992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a.out_800(4) Series 700/800 Implementation a.out_800(4)
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
Hewlett-Packard Company - 13 - HP-UX Release 9.0: August 1992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a.out_800(4) Series 700/800 Implementation a.out_800(4)
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
Hewlett-Packard Company - 14 - HP-UX Release 9.0: August 1992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a.out_800(4) Series 700/800 Implementation a.out_800(4)
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
Hewlett-Packard Company - 15 - HP-UX Release 9.0: August 1992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a.out_800(4) Series 700/800 Implementation a.out_800(4)
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
Hewlett-Packard Company - 16 - HP-UX Release 9.0: August 1992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a.out_800(4) Series 700/800 Implementation a.out_800(4)
|
|
|
|
|
|
|
|
|
|
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);
|
|
|
|
|
|
|
|
Hewlett-Packard Company - 17 - HP-UX Release 9.0: August 1992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a.out_800(4) Series 700/800 Implementation a.out_800(4)
|
|
|
|
|
|
|
|
|
|
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_pt name;
|
|
union name_pt language_name;
|
|
union name_pt product_id;
|
|
union name_pt version_id;
|
|
int reserved;
|
|
struct sys_clock compile_time;
|
|
struct sys_clock source_time;
|
|
};
|
|
|
|
SEE ALSO
|
|
as_300(1), as_800(1), cc(1), ld(1), nm_300(1), nm_800(1), strip(1),
|
|
crt0(3), end(3C), a.out_300(4), magic(4).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Hewlett-Packard Company - 18 - HP-UX Release 9.0: August 1992
|
|
|
|
|
|
|