aout.htm
来自「刚刚看到本站有Visual C++数字图象处理（人民邮电出版社）的电子书」· HTM 代码 · 共 1,084 行 · 第 1/5 页
HTM
1,084 行
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
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).
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.
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 */
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?