|elf(3)||API for manipulating ELF objects|
|elf(5)||format of ELF executable binary files|
|ELF(3)||Library Functions Manual||ELF(3)|
#include <libelf.h>library “libelf” provides functions that allow an application to read and manipulate ELF object files, and to read ar(1) archives. The library allows the manipulation of ELF objects in a byte ordering and word-size independent way, allowing an application to read and create ELF objects for 32 and 64 bit architectures and for little- and big-endian machines. The library is capable of processing ELF objects that use extended section numbering.
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(3) functions that comprise the library.elf(5), ELF files contain several data structures that are laid out in a specific way. ELF files begin with an “Executable Header”, and may contain an optional “Program Header Table”, and optional data in the form of ELF “sections”. A “Section Header Table” describes the content of the data in these sections.
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
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
ELFDATA2MSB for big-endian
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(3) 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(3) library offers translation facilities (elf32_xlatetof(3), elf32_xlatetom(3), elf64_xlatetof(3) and elf64_xlatetom(3)) to and from these representations. It also provides higher-level APIs (gelf_xlatetof(3), gelf_xlatetom(3)) that retrieve and store data from the ELF object in a class-agnostic 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
In the current implementation, all three versions have to be
In addition, the library uses symbols with prefixes
_libelf for its
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
elf64_getehdr() functions. A new Ehdr structure
may be allocated using the
The “Program Header Table” associated with an
ELF descriptor may be allocated using the
elf64_getphdr() functions. A new program header
table may be allocated or an existing table resized using the
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_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
The Elf_Scn descriptor is opaque and contains no application modifiable fields.
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|
||‘.dynamic’ section entries.|
||Symbols for dynamic linking.|
||Termination function pointers.|
||GNU hash sections.|
||List of libraries to be pre-linked.|
||Symbol version definitions.|
||Symbol versioning requirements.|
||Section group marker.|
||Initialization function pointers.|
||Empty sections. See elf(5).|
||ELF note records.|
||Pre-initialization function pointers.|
||ELF relocation records.|
||Relocation records with addends.|
||Used with extended section numbering.|
||Used by dtrace(1).|
||ELF move records.|
||Additional symbol flags.|
Section types in the range [
SHT_HIUSER] are otherwise considered to be of type
However, if the application wishes to take complete charge of the
layout of the ELF file, it may set the
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
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.gelf(3), ar(5), elf(5) FreeBSD 7.0. Joseph Koshy <jkoshy@FreeBSD.org>.
|October 10, 2018||OpenBSD-current|