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