a.out(4)a.out(4)NAMEa.out - assembler and link editor output
SYNOPSISDESCRIPTION
ELF a.out
The file name is the default output file name from the link editor,
ld(1). The link editor will make an executable if there were no errors
in linking. The output file of the assembler, as(1), also follows the
format of the file although its default file name is different.
Programs that manipulate ELF files may use the library that elf(3E)
describes. An overview of the file format follows. For more complete
information, see the references given below.
Linking View Execution View
_______________________ _______________________
ELF header ELF header
|_____________________| |______________________|
|Program header table | | Program header table|
| optional | | |
|_____________________| | _____________________|
| Section 1 | | |
|_____________________| | |
| . . . | | Segment 1 |
| | | |
|_____________________| | _____________________|
| Section n | | |
|_____________________| | |
| . . . | | Segment 2 |
| | | |
|_____________________| | _____________________|
| . . . | | . . . |
|_____________________| | _____________________|
| Section header table| | Section header table|
| | | optional |
|_____________________| | _____________________|
An ELF header resides at the beginning and holds a ``road map''
describing the file's organization. Sections hold the bulk of object
file information for the linking view: instructions, data, symbol ta‐
ble, relocation information, and so on. Segments hold the object file
information for the program execution view. As shown, a segment may
contain one or more sections.
A program header table, if present, tells the system how to create a
process image. Files used to build a process image (execute a program)
must have a program header table; relocatable files do not need one. A
section header table contains information describing the file's sec‐
tions. Every section has an entry in the table; each entry gives
information such as the section name, the section size, and so on.
Files used during linking must have a section header table; other
object files may or may not have one.
Although the figure shows the program header table immediately after
the ELF header, and the section header table following the sections,
actual files may differ. Moreover, sections and segments have no spec‐
ified order. Only the ELF header has a fixed position in the file.
When an file is loaded into memory for execution, three logical seg‐
ments 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 is not writable by the program; if
other processes are executing the same file, the processes will share a
single text segment.
The data segment starts at the next maximal page boundary past the last
text address. (If the system supports more than one page size, the
``maximal page'' is the largest supported size.) When the process
image is created, the part of the file holding the end of text and the
beginning of data may appear twice. The duplicated chunk of text that
appears at the beginning of data is never executed; it is duplicated so
that the operating system may bring in pieces of the file in multiples
of the actual page size without having to realign the beginning of the
data section to a page boundary. Therefore, the first data address is
the sum of the next maximal page boundary past the end of text plus the
remainder of the last text address divided by the maximal page size.
If the last text address is a multiple of the maximal page size, no
duplication is necessary. The stack is automatically extended as
required. The data segment is extended as requested by the brk(2) sys‐
tem call.
SOM a.out (PA-RISC Only)
The file name is the default file name for 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 dic‐
tionary, 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 fol‐
lowing sections: file header, an HP-UX auxiliary header, space dictio‐
nary, 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 sec‐
tions 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 consist of two loadable spaces: a shared, non-writable, code
space named and a private, writable, data space named A program may
contain another loadable, private space named A program may contain
other unloadable spaces that contain data needed by development tools.
For example, symbolic debugging information is contained in a space
named or 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 quad‐
rants. The HP-UX operating system places all code in the first quad‐
rant of the space, all data in the second quadrant of the space, and
all shared library code in 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 archi‐
tecturally 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
$BSS$ Uninitialized data
$TBSS$ Thread local storage
Subspaces can be initialized or uninitialized (although typically, only
and are uninitialized). The subspace dictionary entry for an initial‐
ized 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 contain refer‐
ences 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 infor‐
mation (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 file is loaded into memory for execution, three areas of memory
are set up: the 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 file uses shared libraries, then the dynamic loader is loaded
into memory and called to map into memory all shared libraries
requested by the program. 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
The timestamp is a two-word structure as shown below. If unused, both
fields are zero.
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 head‐
ers are used for two purposes: to attach users' version and copyright
strings to an object file, and to contain the information needed to
load an executable program. In an executable program, the HP-UX auxil‐
iary header must precede all other auxiliary headers. The following
declarations are found in
Space Dictionary
The space dictionary consists of a sequence of space records, as
defined in
The strings for the space names are contained in the space strings ta‐
ble, 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 charac‐
ters 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.
Subspace Dictionary
The subspace dictionary consists of a sequence of subspace records, as
defined in Strings for subspace names are contained in the space
strings table.
Symbol Table
The symbol table consists of a sequence of entries described by the
structure shown below, from Strings for symbol and qualifier names are
contained in the symbol strings table, whose structure is identical
with the space strings table.
The meaning of the symbol value depends on the symbol type. For the
code symbols (generic code, program entry points, procedure and milli‐
code 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 gen‐
erally 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 sym‐
bols, the symbol value is simply the address of the symbol. For thread
local storage symbols (not commons), the symbol value is the thread
local storage offset in a library or executable file, and is the size
of the symbol if in a relocatable object file. For storage requests
and thread local storage commons, the symbol value is the number of
bytes requested; the linker allocates space for the largest request for
each symbol in the or 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, exten‐
sion records follow symbols that define and reference procedure entry
points and global variables. The first extension record, the 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
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.
The field in indicates the minimum alignment of the data, where a value
of represents byte alignment. The values for the and (when the data
type is not hashed) fields in are given in the following table.
Value mode structure arg_type
────────────────────────────────────────────────────────────
0 any any any
1 value parm scalar void
2 reference parm array signed byte
3 value-result struct unsigned byte
4 name pointer signed short
5 variable long ptr unsigned short
6 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 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
instead of on the stack, and the return value is returned in Floating-
point parameters in this range are passed instead in floating-point
registers and a floating-point value is returned in The parameter relo‐
cation 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 param‐
eter word should be marked and the even-numbered parameter word should
be marked Double-precision return values are simply marked
Every procedure call is tagged with a similar set of bits (see "Reloca‐
tion 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
is found in older object files, and the constant 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
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 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 unini‐
tialized 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 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. Copy L bytes with no relocation.
Insert L zero bytes into the output subspace.
Skip L bytes in the output subspace.
Copy one data word with relocation.
The word is assumed to contain a 32-bit pointer relative to its
own subspace.
Copy one data word with relocation relative to an external symbol
whose symbol index is S.
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).
Copy one data word as a space reference.
This fixup request is not currently supported.
Copy L bytes from the input subspace,
replicating the data to fill M bytes in the output subspace.
Copy one instruction word with relocation.
The word is assumed to be a pc-relative procedure call instruc‐
tion (for example, The target procedure is identified by symbol
S, and the parameter relocation bits are R.
Copy one instruction word with relocation.
The word is assumed to be an absolute procedure call instruction
(for example, The target procedure is identified by symbol S,
and the parameter relocation bits are R.
Copy one instruction word with relocation.
The word is assumed to be a dp-relative load or store instruc‐
tion (for example, 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 By convention, the value of is
always contained in register 27. Instructions may have a small
constant in the displacement field of the instruction.
Copy one instruction word with relocation.
The word is assumed to be a register-18-relative load or store
instruction (for example, 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 posi‐
tion-independent code) for the symbol S.
Copy one instruction word with relocation.
The word is assumed to be an instruction referring to symbol S
(for example, Instructions may have a small constant in the dis‐
placement field of the instruction.
Copy one instruction word with relocation.
The word is assumed to be a short millicode call instruction
(for example, 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.
Copy one instruction word with relocation.
The word is assumed to be part of a code sequence forming a pro‐
cedure label (for example, referring to symbol S. The instruc‐
tion should contain the value 0 (no static link) or 2 (static
link required) in its displacement field.
Copy one instruction word conditionally.
On HP-UX, the linker always replaces the word with a instruc‐
tion.
Define a procedure entry point.
The stack unwind bits, U, and the frame size, F, are recorded in
a stack unwind descriptor.
Define an alternate procedure entry point.
Define a procedure exit point.
Define the beginning of a try/recover region.
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.
Define the beginning of a branch table.
Define the end of a branch table.
Define an auxiliary unwind table.
is a symbol index of the symbol that labels the beginning of the
compilation unit string table. is the offset, relative to the
symbol, of the scope name string. is an integer specifying the
scope kind.
Define the beginning of statement number N.
Define the beginning of a secondary statement number N.
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.
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.
Use an F′ field selector for the next fixup request instead of
the default appropriate for the instruction.
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.
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.
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.
Select round-to-nearest-page mode (LS′/RS′).
This setting remains in effect until explicitly changed or until
the end of the subspace.
Select round-up mode (LD′/RD′).
This setting remains in effect until explicitly changed or until
the end of the subspace.
Select round-down-with-adjusted-constant mode (LR′/RR′).
This setting remains in effect until explicitly changed or until
the end of the subspace.
Use the constant V for the next fixup request in place of the constant
from the data word or instruction in the input subspace.
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.
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.
Push the (positive) constant V.
Push the current virtual address.
Pop A and B, then push max(A, B).
Pop A and B, then push min(A, B).
Pop A and B, then push A + B.
Pop A and B, then push B − A.
Pop A and B, then push A * B.
Pop A and B, then push B / A.
Pop A and B, then push B % A.
Pop A and B, then push A & B.
Pop A and B, then push A | B.
Pop A and B, then push A XOR B.
Replace A with its complement.
If C = 0, pop A and B, then push B << A.
Otherwise, replace A with A << C.
If C = 0, pop A and B, then push B >> A.
Otherwise, replace A with A >> C. The shifting is done
with sign extension.
If C = 0, pop A and B, then push B >> A.
Otherwise, replace A with A >> C. The shifting is done
with zero fill.
Push the (negative) constant V.
More stack operations.
Push the (positive) constant V.
Push the value of the symbol S.
Push the value of a procedure label for symbol S.
The static link bit is L.
Push the (negative) constant V.
More stack operations.
Push the value of the procedure entry point S. The parameter
relocation bits are R.
Push the constant V.
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.
Indicates that the following fixup is applied to the first
of a three-instruction sequence to access data, generated by the
compilers to enable the importing of shared library data.
Uses a (N′) field selector for the next fixup request.
This indicates that zero bits are to be used for the displace‐
ment on the instruction. This fixup is used to identify three-
instruction sequences to access data (for importing shared
library data).
Defines the beginning of a line table.
CU is a symbol index of the symbol that labels the beginning of
the line table. SM is the offset relative to the CU symbol. ES
designates the version information for the current line table.
Defines an escape entry to be entered into the line table.
ES designates the escape entry entered in the table. M desig‐
nates the number of R_STATEMENT fixups to be interpreted as raw
8-bit table data.
Override the following fixup,
which is expected to be a R_DATA_ONE_SYMBOL fixup to copy one
data word without relocation when building a shared library.
The absolute byte offset of the symbol relative to the linkage
table pointer is copied. If the linker is building a complete
executable, the absolute virtual address is copied.
Fixup used to pass comment information from the compiler
to the linker. This fixup has a 5 byte argument that can be
skipped and ignored by applications.
Override the next one of these fixups seen:
R_DP_RELATIVE, R_DLT_REL, or R_DATA_ONE_SYMBOL, to use the
thread local storage offset when fixing the instruction. This
fixup is also used to catch thread local storage symbol mis‐
matches.
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 + 1) * 4; M = (B1 + 1) * L
44 5 L = (B1 + 1) * 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 4 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 = sign_extend(B1) * 4
186 4 R = sign_extend(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 = sign_extend(B1)
203 3 V = sign_extend(B2)
204 4 V = sign_extend(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_N0SEL 216 1 none
R_N1SEL 217 1 none
R_SEC_STMT 215 1 none
R_LINETAB 218 9 ES = B1; CU = B3; SM = B4
R_LINETAB_ESC 219 3 ES = B1; M = B1
R_LTP_OVERRIDE 220 1 none
R_COMMENT 221 6 OP = B1; V = B2 to B6
R_TP_OVERRIDE 222 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 gen‐
eral 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 con‐
tribution is the pair of bits for the return value, which are not modi‐
fied. 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 sec‐
ond word. Similarly, the third contribution is formed based on the
third and fourth parameter words. The second contribution is multi‐
plied 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 pro‐
duce 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.
The format of the compilation record is described by the following
structure declaration from
FILESSEE ALSO
System Tools
as(1) Translate assembly code to machine code
cc(1) Invoke the HP-UX C compiler
ld(1) Invoke the link editor
Miscellaneous
crt0(3) Execution startup routine
elf(3E) For the ELF a.out only
end(3C) Symbol of the last locations in program
magic(4) Magic number for HP-UX implementations
nm(1) Print name list of object file
strip(1) Strip symbol and line number information from an object file
a.out(4)