An object file is a black box that you can never really see inside. You can't just open it and read it. We all have some understanding that it contains instructions for the computer, coded in a format that only a computer can understand, but we're used to thinking of compiled program code as something of a mystery. If you take a closer look, however, the structure is not as opaque as you might imagine.

Linux, like most other Unix-like operating systems, stores program code in the Executable and Linkable Format (ELF). ELF superseded the less-flexible a.out format and has been the standard in Linux since 1995 and in FreeBSD [1] since 1998. An ELF object file contains the processor-specific instructions that the CPU actually executes. It also contains other information relating to

• how and where to load the object into memory
• dynamic linking
• any public functions exported (or imported) by the object
• debugging

Much of this functionality is only documented in the source code for kernels and toolchains themselves or in various obscure parts of the web. Understanding the ELF format is essential for anyone writing a compiler, assembler, or linker for the Linux platform.

The best way to study the structure of an ELF file is to watch one come together. In this article, I'll show how to construct an extensible ELF file from scratch using flat assembler (fasm) [2], an x86 macro-assembler. Fasm supports the creation of "flat" binary files, meaning that the programmer determines (broadly speaking) every byte that appears in the output file. The ELF file will run on both Linux and FreeBSD; the full code is about 500 lines, and you can download it from the associated Git repository [3]. You'll need to install fasm from your operating system's package repository.

In your daily life, it is rarely necessary to build an ELF file manually. This exercise is intended for purposes of illustration. In the real world, a developer tool such as a compiler generates the ELF file based on the contents of source code and information provided by the developer.

The Layout of an ELF File

An ELF file usually has four main parts:

• the ELF header
• one or more program headers
• one or more section headers
• one or more sections

Assembly languages operate at a lower level than a language such as C, so assembly language corresponds more closely with the commands the computer actually executes. I'll therefore use assembly language as a means for describing the ELF format. Figure 1 provides a graphical representation of an ELF file and shows how this file relates to the ELF image when loaded into memory.

Figure 1: Inside an ELF File.

The ELF Header

In Listing 1, I declare the ELF header (for those new to assembly language, db means "declare byte," dw means "declare word" (two bytes), and so on; rept n {} repeats the enclosed code n times).

As you can see in Listing 1, the ELF header contains general information describing the program's context. For instance, the header contains settings for the class (32-bit or 64-bit), the Endianness, the operating system, the file type (executable, relocatable object, or shared library), and the processor. The ELF header also marks out the space for the program and section headers, which you'll learn about later in this article.

Program Headers

Each program header describes a memory segment in the final loaded image. Program headers don't have any raw data associated with them; they just tell the loader to allocate memory that will be populated with data from one or more sections. Segments can overlap; you can use the overlap to mark the .dynamic section as both PT_DYNAMIC and PT_LOAD. Because I'm declaring multiple segments, I wrap the declarations in a macro (Listing 2).

I can then declare a program header with a single macro invocation:

PROGRAM_HEADER PT_LOAD,PF_R or PF_X,SECTION_TEXT,LOAD_BASE + PLANE1 +SECTION_TEXT,0,TEXT_PLUS_PLT_SIZE,TEXT_PLUS_PLT_SIZE,0x1000

A segment's offset and alignment must obey the following constraint:

offset mod alignment ==
virtual_address mod alignment &&
offset mod page_size ==
virtual_address mod page_size

(where mod is the integer modulo operator and page_size is usually 4096 for Linux and FreeBSD). The PLANE* constants in the source are there to maintain an appropriate minimum distance of page_size between segments.