a.out -- assembler and link editor output files


COFF files

#include <a.out.h>

ELF files

#include <elf.h>


The filename a.out is the default output filename from the link editor ld(CP). The link editor makes a.out executable if there are no errors in linking. The output file of the assembler, as(CP), also follows the object file formats of the a.out file, although the default filename is different.

ld and as can produce output files in any one of two file formats: Common Object File Format (COFF) and Executable and Linking Format (ELF). See the ld(CP) and as(CP) manual pages for further information. The following sections, ``COFF files'' and ``ELF files'', describe these two file formats.

COFF files

A common object file consists of a file header, a UNIX system header (if the file is link editor output), a table of section headers, relocation information, (optional) line numbers, a symbol table, and a string table. The order is as shown:

File header
UNIX system header

Section 1 header
Section n header

Section 1 data
Section n data

Section 1 relocation
Section n relocation

Section 1 line numbers
Section n line numbers

Symbol table
String table

Some of these parts can be missing:

The sizes of each section (contained in the header, as discussed later) are in bytes.

When an a.out file is loaded into memory for execution, three logical segments are set up:

The text segment starts at location virtual address 0.

The a.out file produced by ld may have one of two magic numbers, 0410 and 0413, in the first field of the UNIX system header. A magic number of 0410 indicates that the executable must be swapped through the private swapping store of the UNIX system, while the magic number 0413 makes the system try to page the text directly from the a.out file.

In a 0410 executable, the text section is loaded at virtual location 0x00000000. The data section is loaded after the text section.

For a 0413 executable, the headers (file header, UNIX system header, and section headers) are loaded at the beginning of the text segment, and the text follows the headers in the user address space. The first text address equals the sum of the sizes of the headers, and varies, depending on the number of sections in the a.out file. In an a.out file with three sections (.text, .data, and .bss), the first text address is at 0x000000D0.

The data section starts in the next page table directory after the last one used by the text section, in the first page of that directory, with an offset into that page equal to the first unused memory offset in the last page of text.

Thus, given that etext is the address of the last byte of the text section, the first byte of the data section is at 0x00400000 + (etext & 0xFFC00000) + ((etext+1) & 0xFFC00FFF).

On an 80386 computer, the stack begins at location 7FFFFFFC and grows toward lower addresses. The stack is automatically extended as required. The data segment is extended only as requested by the brk(S) system call.

For relocatable files, the value of a word in the text or data portions that is not a reference to an undefined external symbol is the value that appears in memory when the file is executed. If a word in the text involves a reference to an undefined external symbol, there is a relocation entry for the word; the storage class of the symbol-table entry for the symbol is marked as an ``external symbol'', and the value and section number of the symbol-table entry are undefined. When the file is processed by the link editor and the external symbol becomes defined, the value of the symbol is added to the word in the file.

File header

The format of the filehdr header is:
struct filehdr
        unsigned short      f_magic;        /* magic number */
        unsigned short      f_nscns;        /* number of sections */
        long                f_timdat;       /* time and date stamp */
        long                f_symptr;       /* file ptr to symtab */
        long                f_nsyms;        /* # symtab entries */
        unsigned short      f_opthdr;       /* sizeof(opt hdr) */
        unsigned short      f_flags;        /* flags */

UNIX system header

The format of the UNIX system header is:
typedef struct aouthdr
        short       magic;        /* magic number */
        short       vstamp;       /* version stamp */
        long        tsize;        /* text size in bytes, padded */
        long        dsize;        /* initialized data (.data) */
        long        bsize;        /* uninitialized data (.bss) */
        long        entry;        /* entry point */
        long        text_start;   /* base of text used for this file */
        long        data_start;   /* base of data used for this file */

Section header

The format of the section header is:
struct scnhdr
        char                s_name[SYMNMLEN]; /* section name */
        long                s_paddr;          /* physical address */
        long                s_vaddr;          /* virtual address */
        long                s_size;           /* section size */
        long                s_scnptr;         /* file ptr to raw data */
        long                s_relptr;         /* file ptr to relocation */
        long                s_lnnoptr;        /* file ptr to line numbers */
        unsigned short      s_nreloc;         /* # reloc entries */
        unsigned short      s_nlnno;          /* # line number entries */
        long                s_flags;          /* flags */


Object files have one relocation entry for each relocatable reference in the text or data. If relocation information is present, it is in the following format:
struct reloc
        long        r_vaddr;       /* (virtual) address of reference */
        long        r_symndx;      /* index into symbol table */
        ushort      r_type;        /* relocation type */
The start of the relocation information is s_relptr from the section header. If there is no relocation information, s_relptr is 0.

Symbol table

The format of each symbol in the symbol table is:
   #define  SYMNMLEN       8
   #define  FILNMLEN       14
   #define  DIMNUM         4

struct syment { union /* all ways to get a symbol name */ { char _n_name[SYMNMLEN]; /* name of symbol */ struct { long _n_zeroes; /* == 0L if in string table */ long _n_offset; /* location in string table */ } _n_n; char *_n_nptr[2]; /* allows overlaying */ } _n; long n_value; /* value of symbol */ short n_scnum; /* section number */ unsigned short n_type; /* type and derived type */ char n_sclass; /* storage class */ char n_numaux; /* number of aux entries */ };

#define n_name _n._n_name #define n_zeroes _n._n_n._n_zeroes #define n_offset _n._n_n._n_offset #define n_nptr _n._n_nptr[1]

Some symbols require more information than a single entry; they are followed by auxiliary entries that are the same size as a symbol entry. The format follows:

   union auxent {
           struct {
                   long        x_tagndx;
                   union {
                           struct {
                                   unsigned short        x_lnno;
                                   unsigned short        x_size;
                           } x_lnsz;
                           long        x_fsize;
                   } x_misc;
                   union {
                           struct {
                                   long        x_lnnoptr;
                                   long        x_endndx;
                           }  x_fcn;
                           struct {
                                   unsigned short        x_dimen[DIMNUM];
                           } x_ary;
                   } x_fcnary;
                   unsigned short  x_tvndx;
           } x_sym;

union { char x_fname[FILNMLEN]; struct { long x_zero; long x_offset; } x_longname; } x_file;

struct { long x_scnlen; unsigned short x_nreloc; unsigned short x_nlinno; } x_scn;

struct { long x_tvfill; unsigned short x_tvlen; unsigned short x_tvran[2]; } x_tv; };

Indexes of symbol table entries begin at zero. The start of the symbol table is f_symptr bytes from the beginning of the file. This value is taken from the file header. If the symbol table is stripped, f_symptr is 0. The string table (if one exists) begins at f_symptr + (f_nsyms * SYMESZ) bytes from the beginning of the file. The macro SYMESZ is defined in <syms.h>.

ELF files

Programs that manipulate ELF files may use the library that is described by the elf(S) manual page. An overview of the file format follows. For more complete information, see the references given later.

Linking View   Execution View
ELF header   ELF header
Program header table   Program header table
Section 1   Segment 1
[. . .]    
Section n Segment 2    
[. . .]    
[. . .]   [. . .]
Section header table   Section header table

 +---------------------+   +----------------------+
 |    Linking View     |   |    Execution View    |
 +---------------------+   +----------------------+
 |     ELF header      |   |      ELF header      |
 |Program header table |   | Program header table |
 |     optional        |   |                      |
 |     Section 1       |   |      Segment 1       |
 |Section n Segment 2  |   |                      |
 |       . . .         |   |                      |
 |       . . .         |   |        . . .         |
 |Section header table |   | Section header table |
 |     optional        |   |                      |

An ELF header resides at the beginning and holds a ``road map'' describing the file's organization. Sections hold the bulk of object file information for the linking view: instructions, data, symbol table, relocation information, and so on. Segments hold the object file information for the program execution view. As shown, a segment may contain one or more sections.

A program header table, if present, tells the system how to create a process image. Files used to build a process image (execute a program) must have a program header table; relocatable files do not need one. A section header table contains information describing the file's sections. Every section has an entry in the table; each entry gives information such as the section name, the section size, and so on. Files used during linking must have a section header table; other object files may or may not have one.

Although the figure shows the program header table immediately after the ELF header, and the section header table following the sections, actual files may differ. Moreover, sections and segments have no specified order. Only the ELF header has a fixed position in the file.

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 is not writable by the program; if other processes are executing the same a.out file, the processes will share a single text segment.

The data segment starts at the next maximal page boundary past the last text address. (If the system supports more than one page size, the ``maximal page'' is the largest supported size.) When the process image is created, the part of the file holding the end of text and the beginning of data may appear twice. The duplicated chunk of text that appears at the beginning of data is never executed; it is duplicated so that the operating system may bring in pieces of the file in multiples of the actual page size without having to realign the beginning of the data section to a page boundary. Therefore, the first data address is the sum of the next maximal page boundary past the end of text plus the remainder of the last text address divided by the maximal page size. If the last text address is a multiple of the maximal page size, no duplication is necessary. The stack is automatically extended as required. The data segment is extended as requested by the brk(S) system call.

Use the file(C) command to display information about whether an ELF object is dynamically or statically linked, was stripped, and whether it contains debug info.

See also

as(CP), cc(CP), ld(CP), brk(S), elf(S), file(C), filehdr(FP), ldfcn(FP), linenum(FP), reloc(FP), scnhdr(FP), syms(FP)
``Common Object File Format (COFF)'' and
``ELF object files'' in Developer's Topics

Standards conformance

a.out(FP) is not part of any currently supported standard; it is an extension of AT&T System V provided by The Santa Cruz Operation, Inc.
© 2003 File Formats for Programming (FP)
SCO OpenServer Release 5.0.7 -- 11 February 2003