elf man page on BSDOS

Man page or keyword search:  
man Server   6284 pages
apropos Keyword Search (all sections)
Output format
BSDOS logo
[printable version]

ELF(5)			    BSD Programmer's Manual			ELF(5)

NAME
     elf - format of ELF binary files

SYNOPSIS
     #include <sys/elf.h>

DESCRIPTION
     The header file <sys/elf.h> defines the format of ELF executable binary
     files.  These files include ordinary executable files, relocatable object
     files, core files and shared libraries.

     ELF files contain an ELF header, plus a program header table or a section
     header table, or both.  The ELF header appears at the beginning of the
     file and provides information about the entire file; the tables appear in
     other locations in the file (specified in the ELF header) and describe
     specific pieces of the file.

     The headers are defined as C structures that contain members with specif-
     ic defined types.	The 32-bit ELF specification uses the following types:

	   Elf32_Addr	 Program addresses.
	   Elf32_Half	 Halfword fields.
	   Elf32_Off	 File offsets.
	   Elf32_Sword	 Signed integers.
	   Elf32_Word	 Fields or unsigned integers.

     The ELF header is described by the type Elf32_Ehdr:

	   typedef {
		   unsigned char   e_ident[EI_NIDENT];
		   Elf32_Half	   e_type;
		   Elf32_Half	   e_machine;
		   Elf32_Word	   e_version;
		   Elf32_Addr	   e_entry;
		   Elf32_Off	   e_phoff;
		   Elf32_Off	   e_shoff;
		   Elf32_Word	   e_flags;
		   Elf32_Half	   e_ehsize;
		   Elf32_Half	   e_phentsize;
		   Elf32_Half	   e_phnum;
		   Elf32_Half	   e_shentsize;
		   Elf32_Half	   e_shnum;
		   Elf32_Half	   e_shstrndx;
	   } Elf32_Ehdr;

     The fields have the following meanings:

     e_ident	    A machine-independent prologue, represented in an array of
		    bytes.  The rest of the ELF file uses the byte order and
		    word size specified by e_ident values.  Bytes in e_ident
		    are named by macros (EI_*), and have values that are also
		    encoded by macros (ELF*). The bytes have the following
		    names and values:

		    EI_MAG0	    The first byte of the magic number; it
				    must have the value ELFMAG0.
		    EI_MAG1	    The second byte, with value ELFMAG1.
		    EI_MAG2	    The third byte, with value ELFMAG2.
		    EI_MAG3	    The fourth byte, with value ELFMAG3.
		    EI_CLASS	    The architecture that corresponds to this
				    binary:

				    ELFCLASS32	  A 32-bit architecture.
				    ELFCLASS64	  A 64-bit architecture.  A
						  64-bit ELF specification is
						  under development; this
						  class is reserved.
		    EI_DATA	    The byte order or data configuration that
				    corresponds to this binary:
				    ELFDATA2LSB	  2's-complement, little-endi-
						  an.
				    ELFDATA2MSB	  2's-complement, big-endian.
		    EI_VERSION	    The version number of the ELF specifica-
				    tion; it must have the value EV_CURRENT.

     e_type	    The type of the ELF file:
		    ET_REL	    A relocatable object file.
		    ET_EXEC	    An executable file.
		    ET_DYN	    A dynamically linked shared library
				    (`shared object').
		    ET_CORE	    A core file.

     e_machine	    The instruction architecture.  Some examples:
		    EM_SPARC	    The Sun SPARC architecture.
		    EM_386	    The Intel x86 architecture.
		    EM_PPC	    The PowerPC architecture.

     e_version	    Must be EV_CURRENT.

     e_entry	    The virtual address of the entry point, if the file type
		    is ET_EXEC or ET_DYN; otherwise zero.

     e_phoff	    The file offset of the program header table.

     e_shoff	    The file offset of the section header table.

     e_flags	    Machine-specific flag bits (EF_*). Not used on the x86 ar-
		    chitecture, and many others.

     e_ehsize	    The ELF header size in bytes.

     e_phentsize    The size of a program header, in bytes.

     e_phnum	    The number of program headers in the program header table.

     e_shentsize    The size of a section header, in bytes.

     e_shnum	    The number of section headers in the section header table.

     e_shstrndx	    The index of the section header in the section header
		    table that contains the section name string table.

     The program header table describes the mapping from the contents of an
     ELF file onto virtual memory.  For example, when the system runs a pro-
     gram, it reads the program header table to locate the text, data and oth-
     er segments in the executable file and to find out where to load them in-
     to memory.	 In a core file, the program header table describes the loca-
     tions and protections of the segments of the dead process, in the file
     and in memory.  The program header table is mandatory except in relocat-
     able object files.	 Program headers have the type Elf32_Phdr:

	   typedef {
		   Elf32_Word	   p_type;
		   Elf32_Off	   p_offset;
		   Elf32_Addr	   p_vaddr;
		   Elf32_Addr	   p_paddr;
		   Elf32_Word	   p_filesz;
		   Elf32_Word	   p_memsz;
		   Elf32_Word	   p_flags;
		   Elf32_Word	   p_align;
	   } Elf32_Phdr;

     The fields have the following meanings:

     p_type	    The type of the information described by this header:
		    PT_NULL	    A placeholder entry.  The contents are ig-
				    nored.
		    PT_LOAD	    A loadable segment.	 This header describes
				    a part of the file that corresponds to
				    memory contents in a process, such as a
				    text or data segment.  Only loadable seg-
				    ments are considered when the system loads
				    a program into memory.  Program headers
				    for loadable segments are ordered by vir-
				    tual address, and the segments don't over-
				    lap.  The other segments don't have these
				    restrictions.
		    PT_DYNAMIC	    Dynamic linking information.  The dynamic
				    linking structures are intricate and var-
				    ied, and are beyond the scope of this man-
				    ual page.
		    PT_INTERP	    The name of an interpreter program.	 The
				    system loads interpreted programs with the
				    interpreter and passes control to the in-
				    terpreter at start-up; the interpreter is
				    responsible for any remaining loading or
				    relocation that must be performed before
				    the program may run.  The typical inter-
				    preter is the dynamic linker, /shlib/ld-
				    bsdi.so.
		    PT_NOTE	    Miscellaneous run-time information.	 This
				    includes material such as `brands', which
				    describe the operating system environment
				    that the program requires.	Core notes are
				    described in core(5).
		    PT_PHDR	    The program header table itself.  Some
				    programs, such as the dynamic linker, need
				    to access information in the program head-
				    er table at run time.

     p_offset	    The byte offset in the ELF file at which the segment
		    starts.

     p_vaddr	    The virtual address where the segment is or was loaded.

     p_paddr	    An unused field; must be zero.

     p_filesz	    The extent of the segment in the executable file, in
		    bytes.

     p_memsz	    The extent of the segment in memory, in bytes.  If p_memsz
		    is greater than p_filesz, the `missing' data is filled
		    with zeroes in memory.

     p_flags	    Protection bits:
		    PF_X	    An executable segment.
		    PF_W	    A writable segment.
		    PF_R	    A readable segment.

     p_align	    If nonzero, the alignment in bytes of the segment; it must
		    be a power of two, and the p_vaddr field must match this
		    alignment modulo the page size.  If zero, the segment need
		    not be aligned.

     A section header table describes the file from the linker's point of
     view.  A section header table is mandatory in relocatable objects and
     shared objects, and is optional in other ELF files.  The linker ld(1) us-
     es the section header table to determine how to combine ELF files.	 Sec-
     tions of the same name are merged in the linking process; for example,
     all sections named `.text' are relocated and concatenated into a single
     text segment.  Different sections that have similar protections are sort-
     ed and merged into common segments.  The first section (index 0) in the
     section header table is reserved as a `null' section.  Section headers
     have the type Elf32_Shdr:

	   typedef struct {
		   Elf32_Word	   sh_name;
		   Elf32_Word	   sh_type;
		   Elf32_Word	   sh_flags;
		   Elf32_Addr	   sh_addr;
		   Elf32_Off	   sh_offset;
		   Elf32_Word	   sh_size;
		   Elf32_Word	   sh_link;
		   Elf32_Word	   sh_info;
		   Elf32_Word	   sh_addralign;
		   Elf32_Word	   sh_entsize;
	   } Elf32_Shdr;

     The fields have the following meanings:

     sh_name	    The name of the section, given as a byte offset into the
		    section header string table.  The index of the section
		    header string table in the section header table is provid-
		    ed in the ELF header (e_shstrndx).

     sh_type	    The type of the contents:
		    SHT_NULL	    An unused section header.
		    SHT_PROGBITS    Information specific to this ELF file.
				    Typically, text or data from a program.
		    SHT_SYMTAB	    A symbol table (see below).
		    SHT_STRTAB	    A string table (see below).
		    SHT_RELA	    A table of relocations with addends.
		    SHT_HASH	    A symbol hash table; usually used to speed
				    up dynamic linking.	 Not described here.
		    SHT_DYNAMIC	    Dynamic linking information.
		    SHT_NOTE	    Miscellaneous information about the file.
		    SHT_NOBITS	    Like SHT_PROGBITS, but for zero-filled
				    memory; the section occupies no space in
				    the file.  It is typically used for bss in
				    a program.
		    SHT_REL	    A table of relocations that don't require
				    addends.
		    SHT_DYNSYM	    A reduced symbol table for dynamic link-
				    ing.

     sh_flags	    Protection bits:
		    SHF_WRITE	    A writable section.	 Sections are readable
				    by default.
		    SHF_ALLOC	    A section that corresponds to virtual mem-
				    ory; typically, part of a loadable seg-
				    ment.
		    SHF_EXECINSTR   An executable section; typically, program
				    text.

     sh_addr	    The address of the section in virtual memory, if it has
		    one; otherwise 0.

     sh_offset	    The byte offset of the section in the file.

     sh_size	    The length in bytes of the section.

     sh_link	    A section header index that means something different de-
		    pending on the type of the section.	 It is defined to be
		    SHN_UNDEF for those sections that don't use it.  For
		    SHT_DYNAMIC, SHT_SYMTAB and SHT_DYNSYM sections, it is the
		    index of the corresponding string table.  For SHT_HASH,
		    SHT_REL and SHT_RELA sections, it is the index of the cor-
		    responding symbol table.

     sh_info	    A cookie that holds a value specific to certain sections.
		    Sections that don't use it give it as 0.  For SHT_SYMTAB
		    and SHT_DYNSYM sections, it contains the symbol table in-
		    dex of the first non-local symbol table entry, or one
		    greater than the index of the last entry if all entries
		    are local (STB_LOCAL). For SHT_REL and SHT_RELA sections,
		    it contains the section header index of the section to
		    which these relocations apply.

     sh_addralign   The maximum alignment of the section, given in bytes.  It
		    must be a power of two, or zero to indicate no alignment
		    requirements.

     sh_entsize	    The size of the elements in this section, if they all have
		    the same size.  For example, in a symbol table section,
		    this field would give the size of a symbol table entry.

     There are several sections that have standard names.  These include the
     .text section, the .data section and the .bss section, which respectively
     contain machine instructions, initialized data and uninitialized (zero-
     filled) data.  There are read-only data sections, debugging sections and
     dynamic linking sections as well; the details will not be described here.

     Sections typically do not have a fixed virtual address.  The linker as-
     signs a final virtual address to a section only after all sections have
     been linked.  Symbols are strings that serve to identify information in
     sections; they stand in for addresses until the linker assigns final ad-
     dresses.  For example, a global variable name or a function name in C
     typically becomes a symbol name in an ELF file.

     Symbols are described by their name, which appears in a string table, and
     by a structure called a symbol table entry. An ELF symbol table entry has
     the type Elf32_Shdr:

	   typedef {
		   Elf32_Word	   st_name;
		   Elf32_Addr	   st_value;
		   Elf32_Word	   st_size;
		   unsigned char   st_info;
		   unsigned char   st_other;
		   Elf32_Half	   st_shndx;
	   } Elf32_Sym;

     The fields have the following meanings:

     st_name	    The index of the nul-terminated symbol name string in the
		    corresponding string table.

     st_value	    The value of the symbol.  This is typically an offset
		    within a section that contains the data corresponding to
		    the symbol, but it may be any arbitrary number.  The
		    st_shndx field controls the interpretation (see below).

     st_size	    The size of the object that the symbol describes, if the

		    object has a size and that size is known; otherwise 0.

     st_info	    A cookie that encodes the binding (scope) and type
		    (format) of the object that the symbol references.	Bind-
		    ings and types are numbers, as opposed to bits.  The
		    available bindings are:
		    STB_LOCAL	    A local symbol.  Local symbols have file
				    scope -- symbols in other files in a link
				    may have the same name.
		    STB_GLOBAL	    A global symbol.  All instances of a given
				    global symbol in a link refer to the same
				    object.  There must be at most one defini-
				    tion of the global symbol across all files
				    in the link; other occurrences of the sym-
				    bol must be `undefined' references (see
				    st_shndx below).
		    STB_WEAK	    A `weak' symbol.  A weak symbol is similar
				    to a global symbol, but with lower prece-
				    dence.  There are two cases: a weak symbol
				    definition, and an undefined weak symbol.
				    Weak symbol definitions have global scope,
				    but there may be more than one definition
				    of a weak symbol in a link, and a weak
				    symbol definition may duplicate a global
				    symbol definition.	If a global definition
				    of a symbol is found during a link, the
				    linker ignores all weak definitions.  In
				    the absence of a global definition, the
				    first weak definition in the link wins.  A
				    weak undefined symbol is like a global un-
				    defined symbol, but it is not an error if
				    a definition for that symbol does not ap-
				    pear in the link.  Also, the linker won't
				    extract an object file from an archive
				    merely to satisfy an undefined weak sym-
				    bol.  Unresolved weak symbols have the
				    value 0.  A global or weak definition is
				    sufficient to resolve an undefined weak
				    symbol.

		    The available types are:
		    STT_NOTYPE	    No type information was provided.
		    STT_OBJECT	    A data object, such as a variable or a
				    structure.
		    STT_FUNC	    A function.
		    STT_SECTION	    A section.	These symbols have local bind-
				    ing and are used for relocation.
		    STT_FILE	    A file name.  Symbols with this type con-
				    ventionally appear first in the symbol
				    table; they have local binding and abso-
				    lute linkage.

		    There are macros for packing and unpacking the binding and
		    type fields:
		    ELF32_ST_INFO (bind, type)
				    Convert a binding and a type into an
				    st_info value.
		    ELF32_ST_BIND (info)
				    Extract a binding from an st_info value.
		    ELF32_ST_TYPE (info)
				    Extract a type from an st_info value.

     st_other	    An unused field.

     st_shndx	    The section header index.  In most cases, this refers to a
		    section header in the section header table, in which case
		    the location of the object to which the symbol refers is
		    st_value bytes from the start of that section.  There are
		    three reserved pseudo-indexes:
		    SHN_UNDEF	    Symbols in this pseudo-section are
				    undefined. The linker must locate a defi-
				    nition in some other file.	The linker re-
				    ports an error if it cannot find a defini-
				    tion (except for weak symbols).
		    SHN_ABS	    These symbols have absolute addresses.
				    The value in the st_value field is not
				    modified by the linker; it is effectively
				    a constant.
		    SHN_COMMON	    These symbols are similar to undefined
				    symbols, but if at the end of the link, no
				    definition has been found, then the linker
				    allocates zero-filled space in the bss
				    segment for a definition.  The object that
				    the linker creates will have the maximum
				    size and alignment found among the common
				    symbols with this name.

     A string table section stores the names of symbols or sections.  A symbol
     or a section header will provide a byte offset into a string table, or
     zero to indicate a null string.  All strings in the string table are nul-
     terminated.  (Thus, the first byte of a non-empty string table is always
     a nul.)  Strings may overlap; they also need not be unique.

     A note section contains miscellaneous information that is of interest to
     the system or to the compiler tools.  It is structured into 12-byte,
     32-bit aligned headers, each of which may be followed by note-specific
     data.  The data is in turn structured into two 32-bit aligned sections.
     The first two header words give the sizes of the two data sections in
     bytes, not including any padding for alignment; the third word provides
     an integer type value.  Conventionally, the first section of data holds a
     nul-terminated name of an operating system or vendor; the length includes
     the nul byte.  The second section and the type word have any value that
     the vendor cares to give them.

     Relocation and dynamic sections are beyond the scope of this document.
     See the System V Application Binary Interface for details.

SEE ALSO
     ld(1),  ld.so(8),	execve(2),  core(5)

HISTORY
     ELF first appeared in Unix System V.  It is a published standard.

BUGS
     Many tools on the system are still oriented toward a.out(5) format binary
     files, even when they support ELF internally.

BSDI BSD/OS		       December 9, 1997				     7
[top]
                             _         _         _ 
                            | |       | |       | |     
                            | |       | |       | |     
                         __ | | __ __ | | __ __ | | __  
                         \ \| |/ / \ \| |/ / \ \| |/ /  
                          \ \ / /   \ \ / /   \ \ / /   
                           \   /     \   /     \   /    
                            \_/       \_/       \_/ 
More information is available in HTML format for server BSDOS

List of man pages available for BSDOS

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net