📄 aout.htm
字号:
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=gb2312">
<title>architecture</title>
<meta name="generator" content="microsoft frontpage 3.0">
</head>
<body background="../jpg/di1.JPG">
<font face="宋体" size="3">
<p align="center"></font><font face="宋体" size="6" color="#0000ff">architecture-dependent
file format</font></p>
<div align="center"><center>
<table border="0" width="88%">
<tr>
<td width="100%"> <pre> 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).
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
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;
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).
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;
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -