HP-UX Reference (11i v2 07/12) - 3 Library Functions A-M (vol 6)

e
elf(3E) elf(3E)
NAME
elf - object file access library
SYNOPSIS
cc [flag... ] file...
-lelf [library] ...
#include <libelf.h>
DESCRIPTION
Functions in the ELF access library let a program manipulate ELF (Executable and Linking Format) object
files, archive files, and archive members. The header file provides type and function declarations for all
library services.
Programs communicate with many of the higher-level routines using an ELF descriptor. That is, when
the program starts working with a file,
elf_begin creates an ELF descriptor through which the program
manipulates the structures and information in the file. These ELF descriptors can be used both to read and
to write files. After the program establishes an ELF descriptor for a file, it may then obtain section descrip-
tors to manipulate the sections of the file (see elf_getscn(3E)). Sections hold the bulk of an object file’s real
information, such as text, data, the symbol table, and so on. A section descriptor ‘‘belongs’’ to a particular
ELF descriptor, just as a section belongs to a file. Finally, data descriptors are available through section
descriptors, allowing the program to manipulate the information associated with a section. A data descrip-
tor ‘‘belongs’’ to a section descriptor.
Descriptors provide private handles to a file and its pieces. In other words, a data descriptor is associated
with one section descriptor, which is associated with one ELF descriptor, which is associated with one file.
Although descriptors are private, they give access to data that may be shared. Consider programs that
combine input files, using incoming data to create or update another file. Such a program might get data
descriptors for an input and an output section. It then could update the output descriptor to reuse the
input descriptor’s data. That is, the descriptors are distinct, but they could share the associated data bytes.
This sharing avoids the space overhead for duplicate buffers and the performance overhead for copying data
unnecessarily.
File Classes
ELF provides a framework in which to define a family of object files, supporting multiple processors and
architectures. An important distinction among object files is the class , or capacity, of the file. The 32-bit
class supports architectures in which a 32-bit object can represent addresses, file sizes, and so forth, as in
the following.
Name Purpose
Elf32_Addr Unsigned address
Elf32_Half Unsigned medium integer
Elf32_Off Unsigned file offset
Elf32_Sword Signed large integer
Elf32_Word Unsigned large integer
unsigned char Unsigned small integer
Other classes will be defined as necessary, to support larger (or smaller) machines. Some library services
deal only with data objects for a specific class, while others are class- independent. To make this distinction
clear, library function names reflect their status, as described below.
Data Representations
Conceptually, two parallel sets of objects support cross compilation environments. One set corresponds to
file contents, while the other set corresponds to the native memory image of the program manipulating the
file. Type definitions supplied by the header files work on the native machine, which may have different
data encodings (size, byte order, and so forth) than the target machine. Although native memory objects
should be at least as big as the file objects (to avoid information loss), they may be bigger if that is more
natural for the host machine.
Translation facilities exist to convert between file and memory representations. Some library routines con-
vert data automatically, while others leave conversion as the program’s responsibility. Either way, pro-
grams that create object files must write file-typed objects to those files; programs that read object files
must take a similar view. See elf_xlate(3E) and elf_fsize(3E) for more information.
HP-UX 11i Version 2: December 2007 Update − 1 − Hewlett-Packard Company 339