xref: /netbsd-src/share/man/man5/a.out.5 (revision ce0bb6e8d2e560ecacbe865a848624f94498063b)
1.\"	$NetBSD: a.out.5,v 1.8 1994/11/30 19:31:09 jtc Exp $
2.\"
3.\" Copyright (c) 1991, 1993
4.\"	The Regents of the University of California.  All rights reserved.
5.\"
6.\" This man page is derived from documentation contributed to Berkeley by
7.\" Donn Seeley at UUNET Technologies, Inc.
8.\"
9.\" Redistribution and use in source and binary forms, with or without
10.\" modification, are permitted provided that the following conditions
11.\" are met:
12.\" 1. Redistributions of source code must retain the above copyright
13.\"    notice, this list of conditions and the following disclaimer.
14.\" 2. Redistributions in binary form must reproduce the above copyright
15.\"    notice, this list of conditions and the following disclaimer in the
16.\"    documentation and/or other materials provided with the distribution.
17.\" 3. All advertising materials mentioning features or use of this software
18.\"    must display the following acknowledgement:
19.\"	This product includes software developed by the University of
20.\"	California, Berkeley and its contributors.
21.\" 4. Neither the name of the University nor the names of its contributors
22.\"    may be used to endorse or promote products derived from this software
23.\"    without specific prior written permission.
24.\"
25.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
26.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
27.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
28.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
29.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
30.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
31.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
32.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
33.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
34.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
35.\" SUCH DAMAGE.
36.\"
37.\"	@(#)a.out.5	8.1 (Berkeley) 6/5/93
38.\"
39.Dd June 5, 1993
40.Dt A.OUT 5
41.Os
42.Sh NAME
43.Nm a.out
44.Nd format of executable binary files
45.Sh SYNOPSIS
46.Fd #include <a.out.h>
47.Sh DESCRIPTION
48The include file
49.Aq Pa a.out.h
50declares three structures and several macros.
51The structures describe the format of
52executable machine code files
53.Pq Sq binaries
54on the system.
55.Pp
56A binary file consists of up to 7 sections.
57In order, these sections are:
58.Bl -tag -width "text relocations"
59.It exec header
60Contains parameters used by the kernel
61to load a binary file into memory and execute it,
62and by the link editor
63.Xr ld 1
64to combine a binary file with other binary files.
65This section is the only mandatory one.
66.It text segment
67Contains machine code and related data
68that are loaded into memory when a program executes.
69May be loaded read-only.
70.It data segment
71Contains initialized data; always loaded into writable memory.
72.It text relocations
73Contains records used by the link editor
74to update pointers in the text segment when combining binary files.
75.It data relocations
76Like the text relocation section, but for data segment pointers.
77.It symbol table
78Contains records used by the link editor
79to cross reference the addresses of named variables and functions
80.Pq Sq symbols
81between binary files.
82.It string table
83Contains the character strings corresponding to the symbol names.
84.El
85.Pp
86Every binary file begins with an
87.Fa exec
88structure:
89.Bd -literal -offset indent
90struct exec {
91	unsigned long	a_midmag;
92	unsigned long	a_text;
93	unsigned long	a_data;
94	unsigned long	a_bss;
95	unsigned long	a_syms;
96	unsigned long	a_entry;
97	unsigned long	a_trsize;
98	unsigned long	a_drsize;
99};
100.Ed
101.Pp
102The fields have the following functions:
103.Bl -tag -width a_trsize
104.It Fa a_midmag
105This field is stored in network byte-order so that binaries for
106for machines with alternate byte orders can be distinguished.
107It has a number of sub-components accessed by the macros
108.Dv N_GETFLAG() ,
109.Dv N_GETMID() , and
110.Dv N_GETMAGIC() ,
111and set by the macro
112.Dv N_SETMAGIC().
113.Pp
114The macro
115.Dv N_GETFLAG()
116returns a few flags:
117.Bl -tag -width EX_DYNAMIC
118.It Dv EX_DYNAMIC
119indicates that the executable requires the services of the run-time link editor.
120.It Dv EX_PIC
121indicates that the object contains position independent code. This flag is
122set by
123.Xr as 1
124when given the
125.Sq -k
126flag and is preserved by
127.Xr ld 1
128if necessary.
129.El
130.Pp
131If both EX_DYNAMIC and EX_PIC are set, the object file is a position indendent
132executable image (eg. a shared library), which is to be loaded into the
133process address space by the run-time link editor.
134.Pp
135The macro
136.Dv N_GETMID()
137returns the machine-id.
138This indicates which machine(s) the binary is intended to run on.
139.Pp
140.Dv N_GETMAGIC()
141specifies the magic number, which uniquely identifies binary files
142and distinguishes different loading conventions.
143The field must contain one of the following values:
144.Bl -tag -width ZMAGIC
145.It Dv OMAGIC
146The text and data segments immediately follow the header
147and are contiguous.
148The kernel loads both text and data segments into writable memory.
149.It Dv NMAGIC
150As with
151.Dv OMAGIC ,
152text and data segments immediately follow the header and are contiguous.
153However, the kernel loads the text into read-only memory
154and loads the data into writable memory at the next
155page boundary after the text.
156.It Dv ZMAGIC
157The kernel loads individual pages on demand from the binary.
158The header, text segment and data segment are all
159padded by the link editor to a multiple of the page size.
160Pages that the kernel loads from the text segment are read-only,
161while pages from the data segment are writable.
162.El
163.It Fa a_text
164Contains the size of the text segment in bytes.
165.It Fa a_data
166Contains the size of the data segment in bytes.
167.It Fa a_bss
168Contains the number of bytes in the
169.Sq bss segment
170and is used by the kernel to set the initial break
171.Pq Xr brk 2
172after the data segment.
173The kernel loads the program so that this amount of writable memory
174appears to follow the data segment and initially reads as zeroes.
175.It Fa a_syms
176Contains the size in bytes of the symbol table section.
177.It Fa a_entry
178Contains the address in memory of the entry point
179of the program after the kernel has loaded it;
180the kernel starts the execution of the program
181from the machine instruction at this address.
182.It Fa a_trsize
183Contains the size in bytes of the text relocation table.
184.It Fa a_drsize
185Contains the size in bytes of the data relocation table.
186.El
187.Pp
188The
189.Pa a.out.h
190include file defines several macros which use an
191.Fa exec
192structure to test consistency or to locate section offsets in the binary file.
193.Bl -tag -width N_BADMAG(exec)
194.It Fn N_BADMAG exec
195Nonzero if the
196.Fa a_magic
197field does not contain a recognized value.
198.It Fn N_TXTOFF exec
199The byte offset in the binary file of the beginning of the text segment.
200.It Fn N_SYMOFF exec
201The byte offset of the beginning of the symbol table.
202.It Fn N_STROFF exec
203The byte offset of the beginning of the string table.
204.El
205.Pp
206Relocation records have a standard format which
207is described by the
208.Fa relocation_info
209structure:
210.Bd -literal -offset indent
211struct relocation_info {
212	int		r_address;
213	unsigned int	r_symbolnum : 24,
214			r_pcrel : 1,
215			r_length : 2,
216			r_extern : 1,
217			r_baserel : 1,
218			r_jmptable : 1,
219			r_relative : 1,
220			r_copy : 1;
221};
222.Ed
223.Pp
224The
225.Fa relocation_info
226fields are used as follows:
227.Bl -tag -width r_symbolnum
228.It Fa r_address
229Contains the byte offset of a pointer that needs to be link-edited.
230Text relocation offsets are reckoned from the start of the text segment,
231and data relocation offsets from the start of the data segment.
232The link editor adds the value that is already stored at this offset
233into the new value that it computes using this relocation record.
234.It Fa r_symbolnum
235Contains the ordinal number of a symbol structure
236in the symbol table (it is
237.Em not
238a byte offset).
239After the link editor resolves the absolute address for this symbol,
240it adds that address to the pointer that is undergoing relocation.
241(If the
242.Fa r_extern
243bit is clear, the situation is different; see below.)
244.It Fa r_pcrel
245If this is set,
246the link editor assumes that it is updating a pointer
247that is part of a machine code instruction using pc-relative addressing.
248The address of the relocated pointer is implicitly added
249to its value when the running program uses it.
250.It Fa r_length
251Contains the log base 2 of the length of the pointer in bytes;
2520 for 1-byte displacements, 1 for 2-byte displacements,
2532 for 4-byte displacements.
254.It Fa r_extern
255Set if this relocation requires an external reference;
256the link editor must use a symbol address to update the pointer.
257When the
258.Fa r_extern
259bit is clear, the relocation is
260.Sq local ;
261the link editor updates the pointer to reflect
262changes in the load addresses of the various segments,
263rather than changes in the value of a symbol (except when
264.Fa r_baserel
265is also set (see below).
266In this case, the content of the
267.Fa r_symbolnum
268field is an
269.Fa n_type
270value (see below);
271this type field tells the link editor
272what segment the relocated pointer points into.
273.It Fa r_baserel
274If set, the symbol, as identified by the
275.Fa r_symbolnum
276field, is to be relocated to an offset into the Global Offset Table.
277At run-time, the entry in the Global Offset Table at this offset is set to
278be the address of the symbol.
279.It Fa r_jmptable
280If set, the symbol, as identified by the
281.Fa r_symbolnum
282field, is to be relocated to an offset into the Procedure Linkage Table.
283.It Fa r_relative
284If set, this relocation is relative to the (run-time) load address of the
285image this object file is going to be a part of. This type of relocation
286only occurs in shared objects.
287.It Fa r_copy
288If set, this relocation record identifies a symbol whose contents should
289be copied to the location given in
290.Fa r_address.
291The copying is done by the run-time link-editor from a suitable data
292item in a shared object.
293.El
294.Pp
295Symbols map names to addresses (or more generally, strings to values).
296Since the link-editor adjusts addresses,
297a symbol's name must be used to stand for its address
298until an absolute value has been assigned.
299Symbols consist of a fixed-length record in the symbol table
300and a variable-length name in the string table.
301The symbol table is an array of
302.Fa nlist
303structures:
304.Bd -literal -offset indent
305struct nlist {
306	union {
307		char	*n_name;
308		long	n_strx;
309	} n_un;
310	unsigned char	n_type;
311	char		n_other;
312	short		n_desc;
313	unsigned long	n_value;
314};
315.Ed
316.Pp
317The fields are used as follows:
318.Bl -tag -width n_un.n_strx
319.It Fa n_un.n_strx
320Contains a byte offset into the string table
321for the name of this symbol.
322When a program accesses a symbol table with the
323.Xr nlist 3
324function,
325this field is replaced with the
326.Fa n_un.n_name
327field, which is a pointer to the string in memory.
328.It Fa n_type
329Used by the link editor to determine
330how to update the symbol's value.
331The
332.Fa n_type
333field is broken down into three sub-fields using bitmasks.
334The link editor treats symbols with the
335.Dv N_EXT
336type bit set as
337.Sq external
338symbols and permits references to them from other binary files.
339The
340.Dv N_TYPE
341mask selects bits of interest to the link editor:
342.Bl -tag -width N_TEXT
343.It Dv N_UNDF
344An undefined symbol.
345The link editor must locate an external symbol with the same name
346in another binary file to determine the absolute value of this symbol.
347As a special case, if the
348.Fa n_value
349field is nonzero and no binary file in the link-edit defines this symbol,
350the link-editor will resolve this symbol to an address
351in the bss segment,
352reserving an amount of bytes equal to
353.Fa n_value .
354If this symbol is undefined in more than one binary file
355and the binary files do not agree on the size,
356the link editor chooses the greatest size found across all binaries.
357.It Dv N_ABS
358An absolute symbol.
359The link editor does not update an absolute symbol.
360.It Dv N_TEXT
361A text symbol.
362This symbol's value is a text address and
363the link editor will update it when it merges binary files.
364.It Dv N_DATA
365A data symbol; similar to
366.Dv N_TEXT
367but for data addresses.
368The values for text and data symbols are not file offsets but
369addresses; to recover the file offsets, it is necessary
370to identify the loaded address of the beginning of the corresponding
371section and subtract it, then add the offset of the section.
372.It Dv N_BSS
373A bss symbol; like text or data symbols but
374has no corresponding offset in the binary file.
375.It Dv N_FN
376A filename symbol.
377The link editor inserts this symbol before
378the other symbols from a binary file when
379merging binary files.
380The name of the symbol is the filename given to the link editor,
381and its value is the first text address from that binary file.
382Filename symbols are not needed for link-editing or loading,
383but are useful for debuggers.
384.El
385.Pp
386The
387.Dv N_STAB
388mask selects bits of interest to symbolic debuggers
389such as
390.Xr gdb 1 ;
391the values are described in
392.Xr stab 5 .
393.It Fa n_other
394This field provides information on the nature of the symbol independent of
395the symbol's location in terms of segments as determined by the
396.Fa n_type
397field. Currently, the lower 4 bits of the
398.Fa n_other
399field hold one of two values:
400.Dv AUX_FUNC
401and
402.Dv AUX_OBJECT
403.Po
404see
405.Aq Pa link.h
406for their definitions
407.Pc .
408.Dv AUX_FUNC
409associates the symbol with a callable function, while
410.Dv AUX_OBJECT
411associates the symbol with data, irrespective of their locations in
412either the text or the data segment.
413This field is intended to be used by
414.Xr ld 1
415for the construction of dynamic executables.
416.It Fa n_desc
417Reserved for use by debuggers; passed untouched by the link editor.
418Different debuggers use this field for different purposes.
419.It Fa n_value
420Contains the value of the symbol.
421For text, data and bss symbols, this is an address;
422for other symbols (such as debugger symbols),
423the value may be arbitrary.
424.El
425.Pp
426The string table consists of an
427.Em unsigned long
428length followed by null-terminated symbol strings.
429The length represents the size of the entire table in bytes,
430so its minimum value (or the offset of the first string)
431is always 4 on 32-bit machines.
432.Sh SEE ALSO
433.Xr as 1 ,
434.Xr gdb 1 ,
435.Xr ld 1 ,
436.Xr brk 2 ,
437.Xr execve 2 ,
438.Xr nlist 3 ,
439.Xr core 5 ,
440.Xr dbx 5 ,
441.Xr stab 5 ,
442.Xr link 5
443.Sh HISTORY
444The
445.Pa a.out.h
446include file appeared in
447.At v7 .
448.Sh BUGS
449Nobody seems to agree on what
450.Em bss
451stands for.
452.Pp
453New binary file formats may be supported in the future,
454and they probably will not be compatible at any level
455with this ancient format.
456