SYMESZ) bytes from the beginning of the file.
The macro SYMESZ is defined in <syms.h>.
|
|
#include <a.out.h>
#include <elf.h>
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.
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:
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.
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 */
};
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 */
} AOUTHDR;
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 */
};
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.
#define SYMNMLEN 8 #define FILNMLEN 14 #define DIMNUM 4struct 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>.
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 | |
| 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.