Museum

Home

Lab Overview

Retrotechnology Articles

Online Manuals

⇒ a.out(4) — DG/UX R4.11

Media Vault

Software Library

Restoration Projects

Artifacts Sought

Related Articles

as(1)

cc(1)

ld(1)

ld-coff(1)

brk(2)

elf(3E)

filehdr(4)

ldfcn(4)

linenum(4)

reloc(4)

syms(4)



a.out(4)                          SDK R4.11                         a.out(4)


NAME
       a.out - assembler and link editor output

SYNOPSIS
       #include <elf.h>         /* for ELF executables   */
       #include <a.out.h>  /* for COFF executables */

DESCRIPTION
       The filename a.out is the default output filename from the link
       editor ld(1).  The link editor will make a.out executable if there
       were no errors in linking.  The output file of the assembler, as(1),
       also follows the common object file format of the a.out file although
       the default filename is different.

   ELF (Executable and Linking Format) Files
       Programs that manipulate ELF files may use the library that elf(3E)
       describes.  An overview of the file format follows.  For more
       complete information, see the references given below.


                      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, etc.
       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(2) system call.

   COFF (Common Object File Format) 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 given below:

                 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.

       The last three parts of an object file (line numbers, symbol table
       and string table) may be missing if the program was linked with the
       -s option of ld(1) or if they were removed by strip(1).  Also note
       that the relocation information will be absent after linking unless
       the -r option of ld(1) was used.  The string table exists only if the
       symbol table contains symbols with names longer than eight
       characters.

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

       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.  On the M88K computer the text segment
       typically starts at location 0x00010000 plus the byte offset in the
       a.out file of the text section data.

       The first 16 bits of a.out files is the magic number.  For non-
       executable a.out files and executables linked in the m88kbcs SDE, the
       magic number is 0555.For executables linked in the dgux SDE, the
       magic number is 0541.  See sde(1).  The optional header of an a.out
       file produced by ld(1) also has a magic number whose value is 0413.
       The headers (file header, optional header, and section headers)
       appear at the beginning of a.out files and determine the address of
       the text segment when it is loaded into memory.  The first text
       address will equal 0x00010000 plus the size of the headers, and will
       vary depending upon the number of section headers in the a.out file.
       In an a.out file with three sections (.text, .data, and .bss), the
       first text address is at 0x000100B8 on the M88K computer.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.

       On the M88K computer the stack begins at location 0xF000000 and grows
       toward lower addresses.  The stack is automatically extended as
       required.  The data segment is extended only as requested by the
       brk(2) 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
       exactly the value that will appear in memory when the file is
       executed.  If a word in text or data involves a reference to an
       undefined external symbol, there will be a relocation entry for the
       word, the storage class of the symbol-table entry for the symbol will
       be marked as an ``external symbol'', and the value and section number
       of the symbol-table entry will be undefined.  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.

       The format of the filehdr header is

       struct filehdr
       {
           unsigned short   fmagic;    /* magic number */
           unsigned short   fnscns;    /* number of sections */
           long             ftimdat;   /* time and date stamp */
           long             fsymptr;   /* file ptr to symtab */
           long             fnsyms;    /* # symtab entries */
           unsigned short   fopthdr;   /* sizeof(opt hdr) */
           unsigned short   fflags;    /* flags */
       };

       The format of the optional 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     textstart;  /* base of text used for this file */
           long     datastart;  /* base of data used for this file */
       } AOUTHDR;

       The format of the section header is

       struct scnhdr
       {
           char             sname[8];  /* section name */
           long             spaddr;    /* physical address */
           long             svaddr;    /* virtual address */
           long             ssize;     /* section size */
           long             sscnptr;   /* file ptr to raw data */
           long             srelptr;   /* file ptr to relocation */
           long             slnnoptr;  /* file ptr to line numbers */
           unsigned long    snreloc;   /* # reloc entries */
           unsigned long    snlnno;    /* # line number entries */
           long             sflags;    /* flags */
       };

       Object files have one relocation entry for each relocatable reference
       in the text or data.  If relocation information is present, it will
       be in the following format:

       struct reloc
       {
           long             rvaddr;    /* (virtual) address of reference */
           long             rsymndx;   /* index into symbol table */
           unsigned short   rtype;     /* relocation type */
           unsigned short   roffset;   /* high 16 bits of expression */
       };

       The start of the relocation information is srelptr from the section
       header.  If there is no relocation information, srelptr is 0.

       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        nname[SYMNMLEN]; /* name of symbol */
               struct
               {
                   long    nzeroes;    /* == 0L if in string table */
                   long    noffset;    /* location in string table */
               } nn;
               char        *nnptr[2];  /* allows overlaying */
           } n;
           long            nvalue;      /* value of symbol */
           short           nscnum;      /* section number */
           unsigned short  ntype;       /* type and derived type */
           char            nsclass;     /* storage class */
           char            nnumaux;     /* number of aux entries */
           char            npad1;       /* pad to 4 byte multiple */
           char            npad2;       /* pad to 4 byte multiple */
       };

       #define  nname    n.nname
       #define  nzeroes  n.nn.nzeroes
       #define  noffset  n.nn.noffset
       #define  nnptr    n.nnptr[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   xtagndx;
                     union {
                            struct {
                                     unsigned long   xlnno;
                                     unsigned long   xsize;
                            } xlnsz;
                            long     xfsize;
                     } xmisc;
                     union {
                            struct {
                                     long   xlnnoptr;
                                     long   xendndx;
                            }  xfcn;
                            struct {
                                     unsigned short  xdimen[4];
                            } xary;
                               struct {
                                       unsigned long   xdimen1[2];
                           } xary1;



                     } xfcnary;
                     unsigned short  xtvndx;
                     char xpad1;
                     char xpad2;
              } xsym;

               struct {
                   unsigned long xdimen2[5];
               } xary2;

               union {
                     char   xfname[FILNMLEN];
                       struct {
                           long xzeroes;      /* 0 if name is in string table*/
                           long xoffset;      /* offset into string table */
                       } xx;
                       char     *xxptr[2];    /* allows for overlaying */
               } xfile;
              } xfile;

              struct {
                     long       xscnlen;
                     unsigned short  xnreloc;
                     unsigned short  xnlinno;
              } xscn;

              struct {
                     long            xtvfill;
                     unsigned short  xtvlen;
                     unsigned short  xtvran[2];
              } xtv;
       };

       Indexes of symbol table entries begin at zero.  The start of the
       symbol table is fsymptr (from the file header) bytes from the
       beginning of the file.  If the symbol table is stripped, fsymptr is
       0.  The string table (if one exists) begins at fsymptr + (fnsyms *
       SYMESZ) bytes from the beginning of the file.

SEE ALSO
       as(1), attdump(1), cc(1), ld(1), ld-coff(1), brk(2), elf(3E),
       filehdr(4), ldfcn(4), linenum(4), reloc(4), syms(4).
       The ``Object Files'' chapter in the Programmer's Guide: ANSI C and
       Programming Support Tools.


Licensed material--property of copyright holder(s)

Typewritten Software • bear@typewritten.org • Edmonds, WA 98026