Deleted Added
full compact
a.out.5 (1639) a.out.5 (5210)
1.\" Copyright (c) 1991, 1993
2.\" The Regents of the University of California. All rights reserved.
3.\"
4.\" This man page is derived from documentation contributed to Berkeley by
5.\" Donn Seeley at UUNET Technologies, Inc.
6.\"
7.\" Redistribution and use in source and binary forms, with or without
8.\" modification, are permitted provided that the following conditions

--- 19 unchanged lines hidden (view full) ---

28.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
29.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
30.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
31.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
32.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
33.\" SUCH DAMAGE.
34.\"
35.\" @(#)a.out.5 8.1 (Berkeley) 6/5/93
1.\" Copyright (c) 1991, 1993
2.\" The Regents of the University of California. All rights reserved.
3.\"
4.\" This man page is derived from documentation contributed to Berkeley by
5.\" Donn Seeley at UUNET Technologies, Inc.
6.\"
7.\" Redistribution and use in source and binary forms, with or without
8.\" modification, are permitted provided that the following conditions

--- 19 unchanged lines hidden (view full) ---

28.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
29.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
30.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
31.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
32.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
33.\" SUCH DAMAGE.
34.\"
35.\" @(#)a.out.5 8.1 (Berkeley) 6/5/93
36.\" $Id$
36.\"
37.Dd June 5, 1993
38.Dt A.OUT 5
39.Os
40.Sh NAME
41.Nm a.out
42.Nd format of executable binary files
43.Sh SYNOPSIS

--- 37 unchanged lines hidden (view full) ---

81Contains the character strings corresponding to the symbol names.
82.El
83.Pp
84Every binary file begins with an
85.Fa exec
86structure:
87.Bd -literal -offset indent
88struct exec {
37.\"
38.Dd June 5, 1993
39.Dt A.OUT 5
40.Os
41.Sh NAME
42.Nm a.out
43.Nd format of executable binary files
44.Sh SYNOPSIS

--- 37 unchanged lines hidden (view full) ---

82Contains the character strings corresponding to the symbol names.
83.El
84.Pp
85Every binary file begins with an
86.Fa exec
87structure:
88.Bd -literal -offset indent
89struct exec {
89 unsigned short a_mid;
90 unsigned short a_magic;
90 unsigned long a_midmag;
91 unsigned long a_text;
92 unsigned long a_data;
93 unsigned long a_bss;
94 unsigned long a_syms;
95 unsigned long a_entry;
96 unsigned long a_trsize;
97 unsigned long a_drsize;
98};
99.Ed
100.Pp
101The fields have the following functions:
102.Bl -tag -width a_trsize
91 unsigned long a_text;
92 unsigned long a_data;
93 unsigned long a_bss;
94 unsigned long a_syms;
95 unsigned long a_entry;
96 unsigned long a_trsize;
97 unsigned long a_drsize;
98};
99.Ed
100.Pp
101The fields have the following functions:
102.Bl -tag -width a_trsize
103.It Fa a_mid
104Contains a bit pattern that
105identifies binaries that were built for
106certain sub-classes of an architecture
107.Pq Sq machine IDs
108or variants of the operating system on a given architecture.
109The kernel may not support all machine IDs
110on a given architecture.
111The
112.Fa a_mid
113field is not present on some architectures;
114in this case, the
115.Fa a_magic
116field has type
117.Em unsigned long .
118.It Fa a_magic
119Contains a bit pattern
120.Pq Sq magic number
121that uniquely identifies binary files
103.It Fa a_midmag
104This field is stored in host byte-order.
105It has a number of sub-components accessed by the macros
106.Dv N_GETFLAG() ,
107.Dv N_GETMID() , and
108.Dv N_GETMAGIC() ,
109and set by the macro
110.Dv N_SETMAGIC().
111.Pp
112The macro
113.Dv N_GETFLAG()
114returns a few flags:
115.Bl -tag -width EX_DYNAMIC
116.It Dv EX_DYNAMIC
117indicates that the executable requires the services of the run-time link editor.
118.It Dv EX_PIC
119indicates that the object contains position independent code. This flag is
120set by
121.Xr as 1
122when given the
123.Sq -k
124flag and is preserved by
125.Xr ld 1
126if necessary.
127.El
128.Pp
129If both EX_DYNAMIC and EX_PIC are set, the object file is a position indendent
130executable image (eg. a shared library), which is to be loaded into the
131process address space by the run-time link editor.
132.Pp
133The macro
134.Dv N_GETMID()
135returns the machine-id.
136This indicates which machine(s) the binary is intended to run on.
137.Pp
138.Dv N_GETMAGIC()
139specifies the magic number, which uniquely identifies binary files
122and distinguishes different loading conventions.
123The field must contain one of the following values:
124.Bl -tag -width ZMAGIC
125.It Dv OMAGIC
126The text and data segments immediately follow the header
127and are contiguous.
128The kernel loads both text and data segments into writable memory.
129.It Dv NMAGIC

--- 59 unchanged lines hidden (view full) ---

189structure:
190.Bd -literal -offset indent
191struct relocation_info {
192 int r_address;
193 unsigned int r_symbolnum : 24,
194 r_pcrel : 1,
195 r_length : 2,
196 r_extern : 1,
140and distinguishes different loading conventions.
141The field must contain one of the following values:
142.Bl -tag -width ZMAGIC
143.It Dv OMAGIC
144The text and data segments immediately follow the header
145and are contiguous.
146The kernel loads both text and data segments into writable memory.
147.It Dv NMAGIC

--- 59 unchanged lines hidden (view full) ---

207structure:
208.Bd -literal -offset indent
209struct relocation_info {
210 int r_address;
211 unsigned int r_symbolnum : 24,
212 r_pcrel : 1,
213 r_length : 2,
214 r_extern : 1,
197 : 4;
215 r_baserel : 1,
216 r_jmptable : 1,
217 r_relative : 1,
218 r_copy : 1;
198};
199.Ed
200.Pp
201The
202.Fa relocation_info
203fields are used as follows:
204.Bl -tag -width r_symbolnum
205.It Fa r_address

--- 26 unchanged lines hidden (view full) ---

232Set if this relocation requires an external reference;
233the link editor must use a symbol address to update the pointer.
234When the
235.Fa r_extern
236bit is clear, the relocation is
237.Sq local ;
238the link editor updates the pointer to reflect
239changes in the load addresses of the various segments,
219};
220.Ed
221.Pp
222The
223.Fa relocation_info
224fields are used as follows:
225.Bl -tag -width r_symbolnum
226.It Fa r_address

--- 26 unchanged lines hidden (view full) ---

253Set if this relocation requires an external reference;
254the link editor must use a symbol address to update the pointer.
255When the
256.Fa r_extern
257bit is clear, the relocation is
258.Sq local ;
259the link editor updates the pointer to reflect
260changes in the load addresses of the various segments,
240rather than changes in the value of a symbol.
261rather than changes in the value of a symbol (except when
262.Fa r_baserel
263is also set (see below).
241In this case, the content of the
242.Fa r_symbolnum
243field is an
244.Fa n_type
245value (see below);
246this type field tells the link editor
247what segment the relocated pointer points into.
264In this case, the content of the
265.Fa r_symbolnum
266field is an
267.Fa n_type
268value (see below);
269this type field tells the link editor
270what segment the relocated pointer points into.
271.It Fa r_baserel
272If set, the symbol, as identified by the
273.Fa r_symbolnum
274field, is to be relocated to an offset into the Global Offset Table.
275At run-time, the entry in the Global Offset Table at this offset is set to
276be the address of the symbol.
277.It Fa r_jmptable
278If set, the symbol, as identified by the
279.Fa r_symbolnum
280field, is to be relocated to an offset into the Procedure Linkage Table.
281.It Fa r_relative
282If set, this relocation is relative to the (run-time) load address of the
283image this object file is going to be a part of. This type of relocation
284only occurs in shared objects.
285.It Fa r_copy
286If set, this relocation record identifies a symbol whose contents should
287be copied to the location given in
288.Fa r_address.
289The copying is done by the run-time link-editor from a suitable data
290item in a shared object.
248.El
249.Pp
250Symbols map names to addresses (or more generally, strings to values).
251Since the link-editor adjusts addresses,
252a symbol's name must be used to stand for its address
253until an absolute value has been assigned.
254Symbols consist of a fixed-length record in the symbol table
255and a variable-length name in the string table.

--- 85 unchanged lines hidden (view full) ---

341The
342.Dv N_STAB
343mask selects bits of interest to symbolic debuggers
344such as
345.Xr gdb 1 ;
346the values are described in
347.Xr stab 5 .
348.It Fa n_other
291.El
292.Pp
293Symbols map names to addresses (or more generally, strings to values).
294Since the link-editor adjusts addresses,
295a symbol's name must be used to stand for its address
296until an absolute value has been assigned.
297Symbols consist of a fixed-length record in the symbol table
298and a variable-length name in the string table.

--- 85 unchanged lines hidden (view full) ---

384The
385.Dv N_STAB
386mask selects bits of interest to symbolic debuggers
387such as
388.Xr gdb 1 ;
389the values are described in
390.Xr stab 5 .
391.It Fa n_other
349This field is currently unused.
392This field provides information on the nature of the symbol independent of
393the symbol's location in terms of segments as determined by the
394.Fa n_type
395field. Currently, the lower 4 bits of the
396.Fa n_other
397field hold one of two values:
398.Dv AUX_FUNC
399and
400.Dv AUX_OBJECT
401.Po
402see
403.Aq Pa link.h
404for their definitions
405.Pc .
406.Dv AUX_FUNC
407associates the symbol with a callable function, while
408.Dv AUX_OBJECT
409associates the symbol with data, irrespective of their locations in
410either the text or the data segment.
411This field is intended to be used by
412.Xr ld 1
413for the construction of dynamic executables.
350.It Fa n_desc
351Reserved for use by debuggers; passed untouched by the link editor.
352Different debuggers use this field for different purposes.
353.It Fa n_value
354Contains the value of the symbol.
355For text, data and bss symbols, this is an address;
356for other symbols (such as debugger symbols),
357the value may be arbitrary.
358.El
359.Pp
360The string table consists of an
361.Em unsigned long
362length followed by null-terminated symbol strings.
363The length represents the size of the entire table in bytes,
364so its minimum value (or the offset of the first string)
365is always 4 on 32-bit machines.
366.Sh SEE ALSO
414.It Fa n_desc
415Reserved for use by debuggers; passed untouched by the link editor.
416Different debuggers use this field for different purposes.
417.It Fa n_value
418Contains the value of the symbol.
419For text, data and bss symbols, this is an address;
420for other symbols (such as debugger symbols),
421the value may be arbitrary.
422.El
423.Pp
424The string table consists of an
425.Em unsigned long
426length followed by null-terminated symbol strings.
427The length represents the size of the entire table in bytes,
428so its minimum value (or the offset of the first string)
429is always 4 on 32-bit machines.
430.Sh SEE ALSO
431.Xr as 1 ,
432.Xr gdb 1 ,
367.Xr ld 1 ,
433.Xr ld 1 ,
434.Xr brk 2 ,
368.Xr execve 2 ,
369.Xr nlist 3 ,
370.Xr core 5 ,
371.Xr dbx 5 ,
435.Xr execve 2 ,
436.Xr nlist 3 ,
437.Xr core 5 ,
438.Xr dbx 5 ,
372.Xr stab 5
439.Xr stab 5 ,
440.Xr link 5
373.Sh HISTORY
374The
375.Pa a.out.h
376include file appeared in
377.At v7 .
378.Sh BUGS
379Since not all of the supported architectures use the
441.Sh HISTORY
442The
443.Pa a.out.h
444include file appeared in
445.At v7 .
446.Sh BUGS
447Since not all of the supported architectures use the
380.Fa a_mid
448.Fa a_midmag
381field,
382it can be difficult to determine what
383architecture a binary will execute on
384without examining its actual machine code.
385Even with a machine identifier,
386the byte order of the
387.Fa exec
388header is machine-dependent.
389.Pp
390Nobody seems to agree on what
391.Em bss
392stands for.
393.Pp
394New binary file formats may be supported in the future,
395and they probably will not be compatible at any level
396with this ancient format.
449field,
450it can be difficult to determine what
451architecture a binary will execute on
452without examining its actual machine code.
453Even with a machine identifier,
454the byte order of the
455.Fa exec
456header is machine-dependent.
457.Pp
458Nobody seems to agree on what
459.Em bss
460stands for.
461.Pp
462New binary file formats may be supported in the future,
463and they probably will not be compatible at any level
464with this ancient format.