| ELF(3) | Library Functions Manual | ELF(3) | 
elf —
#include <libelf.h>
This manual page serves to provide an overview of the
    functionality in the ELF library. Further information may found in the
    manual pages for individual elf functions that
    comprise the library.
ELF objects have an associated “ELF class” which
    denotes the natural machine word size for the architecture the object is
    associated with. Objects for 32 bit architectures have an ELF class of
    ELFCLASS32. Objects for 64 bit architectures have an
    ELF class of ELFCLASS64.
ELF objects also have an associated “endianness”
    which denotes the endianness of the machine architecture associated with the
    object. This may be ELFDATA2LSB for little-endian
    architectures and ELFDATA2MSB for big-endian
    architectures.
ELF objects are also associated with an API version number. This version number determines the layout of the individual components of an ELF file and the semantics associated with these.
elf library distinguishes between
  “native” representations of ELF data structures and their
  “file” representations.
An application would work with ELF data in its “native” representation, i.e., using the native byteorder and alignment mandated by the processor the application is running on. The “file” representation of the same data could use a different byte ordering and follow different constraints on object alignment than these native constraints.
Accordingly, the elf library offers
    translation facilities
    (elf32_xlatetof(3),
    elf32_xlatetom(3),
    elf64_xlatetof(3) and
    elf64_xlatetom(3)) to
    and from these representations and also provides higher-level APIs that
    retrieve and store data from the ELF object in a transparent manner.
In order to facilitate working with ELF objects of differing
    versions, the ELF library requires the application to call the
    elf_version() function before invoking many of its
    operations, in order to inform the library of the application's desired
    working version.
In the current implementation, all three versions have to be
    EV_CURRENT.
elf_elf32_elf64_Elf_ELF_C_Elf_Cmd enumeration.ELF_E_ELF_F_ELF_K_ELF_T_In addition, the library uses symbols with prefixes
    _ELF and _libelf for its
    internal use.
elf_begin() or
      elf_memory() functions. An
      Elf descriptor can be used to read and write data to
      an ELF file. An Elf descriptor can be associated
      with zero or more Elf_Scn section descriptors.
    Given an ELF descriptor, the application may retrieve the ELF
        object's class-dependent “Executable Header” structures
        using the elf32_getehdr() or
        elf64_getehdr() functions. A new Ehdr structure
        may be allocated using the elf64_newehdr() or
        elf64_newehdr() functions.
The “Program Header Table” associated with an
        ELF descriptor may be allocated using the
        elf32_getphdr() or
        elf64_getphdr() functions. A new program header
        table may be allocated or an existing table resized using the
        elf32_newphdr() or
        elf64_newphdr() functions.
The Elf structure is opaque and has no members visible to the application.
Elf_Data descriptors are usually
        associated with Elf_Scn descriptors. Existing data
        descriptors associated with an ELF section may be structures are
        retrieved using the elf_getdata() and
        elf_rawdata() functions. The
        elf_newdata() function may be used to attach new
        data descriptors to an ELF section.
They are retrieved using the
        elf_getscn() function. An application may
        iterate through the existing sections of an ELF object using the
        elf_nextscn() function. New sections may be
        allocated using the elf_newscn() function.
The Elf_Scn descriptor is opaque and contains no application modifiable fields.
ELF_T_ADDRELF_T_BYTEELF_T_CAPELF_T_DYNSHT_DYNAMIC.ELF_T_EHDRELF_T_GNUHASHELF_T_HALFELF_T_LWORDELF_T_MOVEELF_T_NOTEELF_T_OFFELF_T_PHDRELF_T_RELELF_T_RELAELF_T_SHDRELF_T_SWORDELF_T_SXWORDELF_T_SYMINFOELF_T_SYMELF_T_VDEFELF_T_VNEEDELF_T_WORDELF_T_XWORDThe symbol ELF_T_NUM denotes the number of
    Elf types known to the library.
The following table shows the mapping between ELF section types defined in elf(5) and the types supported by the library.
| Section Type | Library Type | Description | 
| SHT_DYNAMIC | ELF_T_DYN | ‘.dynamic’ section entries. | 
| SHT_DYNSYM | ELF_T_SYM | Symbols for dynamic linking. | 
| SHT_FINI_ARRAY | ELF_T_ADDR | Termination function pointers. | 
| SHT_GNU_HASH | ELF_T_GNUHASH | GNU hash sections. | 
| SHT_GNU_LIBLIST | ELF_T_WORD | List of libraries to be pre-linked. | 
| SHT_GNU_verdef | ELF_T_VDEF | Symbol version definitions. | 
| SHT_GNU_verneed | ELF_T_VNEED | Symbol versioning requirements. | 
| SHT_GNU_versym | ELF_T_HALF | Version symbols. | 
| SHT_GROUP | ELF_T_WORD | Section group marker. | 
| SHT_HASH | ELF_T_HASH | Symbol hashes. | 
| SHT_INIT_ARRAY | ELF_T_ADDR | Initialization function pointers. | 
| SHT_NOBITS | ELF_T_BYTE | Empty sections. See elf(5). | 
| SHT_NOTE | ELF_T_NOTE | ELF note records. | 
| SHT_PREINIT_ARRAY | ELF_T_ADDR | Pre-initialization function pointers. | 
| SHT_PROGBITS | ELF_T_BYTE | Machine code. | 
| SHT_REL | ELF_T_REL | ELF relocation records. | 
| SHT_RELA | ELF_T_RELA | Relocation records with addends. | 
| SHT_STRTAB | ELF_T_BYTE | String tables. | 
| SHT_SYMTAB | ELF_T_SYM | Symbol tables. | 
| SHT_SYMTAB_SHNDX | ELF_T_WORD | Used with extended section numbering. | 
| SHT_SUNW_dof | ELF_T_BYTE | Used by dtrace(1). | 
| SHT_SUNW_move | ELF_T_MOVE | ELF move records. | 
| SHT_SUNW_syminfo | ELF_T_SYMINFO | Additional symbol flags. | 
| SHT_SUNW_verdef | ELF_T_VDEF | Same as SHT_GNU_verdef. | 
| SHT_SUNW_verneed | ELF_T_VNEED | Same as SHT_GNU_verneed. | 
| SHT_SUNW_versym | ELF_T_HALF | Same as SHT_GNU_versym. | 
Section types in the range [SHT_LOOS,
    SHT_HIUSER] are otherwise considered to be of type
    ELF_T_BYTE.
elf_getdata()elf_getscn()elf_ndxscn()elf_newdata()elf_newscn()elf_nextscn()elf_rawdata()elf_rawfile()elf32_getehdr(),
        elf64_getehdr()elf32_getphdr(),
        elf64_getphdr()elf32_getshdr(),
        elf64_getshdr()elf32_newehdr(),
        elf64_newehdr()elf32_newphdr(),
        elf64_newphdr()elf32_xlatetof(),
        elf64_xlatetof()elf32_xlatetom(),
        elf64_xlatetom()elf_errno()elf_errmsg()elf_cntl()elf_flagdata()elf_flagehdr()elf_flagphdr()elf_flagscn()elf_flagshdr()elf_setshstrndx()elf_update()elf32_checksum(),
        elf64_checkum()elf_getident()elf_getshnum()elf_getshstrndx()elf_hash()elf_kind()elf32_fsize(),
        elf64_fsize()However, if the application wishes to take complete charge of the
    layout of the ELF file, it may set the ELF_F_LAYOUT
    flag on an ELF descriptor using
    elf_flagelf(3), following
    which the library will use the data offsets and alignments specified by the
    application when laying out the file. Application control of file layout is
    described further in the
    elf_update(3) manual
  page.
Gaps in between sections will be filled with the fill character
    set by function elf_fill().
Conversely the library will not free data that it has not allocated. As an example, an application may call elf_newdata(3) to allocate a new Elf_Data descriptor and can set the d_off member of the descriptor to point to a region of memory allocated using malloc(3). It is the applications responsibility to free this arena, though the library will reclaim the space used by the Elf_Data descriptor itself.
| July 28, 2014 | NetBSD 9.3 |