The Section Headers

Each section header describes one section, including its type, permissions, size, and location (on disk and in memory), and other miscellaneous information. The raw data for the sections appears at the end of the ELF file. This raw data consists of executable code, program data such as global objects, and information used in the link. Some ELF images could also contain debugging data in DWARF format.

Table 1 shows some common section names and their descriptions. Most of these need little explanation. Note that the capitalized section names used in the source code don't make it into the final ELF file; they're just labels for the benefit of the assembler. The real section names are by convention lowercase and start with a dot. For more information on the .gnu.hash section, see "GNU Hash ELF Sections" online [4]; the accompanying Git repository contains a small C utility that will generate a GNU-style hash for any symbol.

As with the program headers, section headers have a common format, so I wrap the declarations in a macro (Listing 3).

We can then declare a section header with just one macro invocation:

SECTION_HEADER TEXT,SHSTRTAB.S6,SHT_PROGBITS,SHF_ALLOCor SHF_EXECINSTR,
LOAD_BASE + PLANE1 + SECTION_TEXT,SECTION_TEXT,TEXT_SIZE,0,0,0x10,0x0

Section Contents

This simple example does not require all the sections described in Table 1, but a brief description of the .text, .plt, .got.plt, and .rela.plt sections will give you an indication of how the sections are structured.

The .text section contains the executable code for the program proper (Listing 4). In this case, the code calls puts to print a string to the terminal and exit to return control to the operating system.

x86-64 instructions often use relative addressing. This means that, for example, a CALL instruction is encoded differently depending on its distance from the code it's calling (the destination is encoded as a signed 32-bit value). This makes it impossible to encode an absolute address or call a function whose offset won't fit in 32 bits. The solution is the Procedure Linkage table (PLT) and the Global Offset Table (GOT), which are described in the .plt and got.plt sections. The PLT provides call destinations that are local to the ELF image, so all of its labels can be reached by a 32-bit relative call. It then uses a JMP instruction to jump to the real function, whose address the dynamic linker has placed in the GOT. The PLT and GOT also allow the dynamic linker to resolve function addresses only when required, speeding up the loading process.

Listing 5 defines some convenience macros for the .plt and got.plt sections and then lists the sections themselves.

Next I use the .rela.plt section to define a macro for a single relocation, using the 24-byte structure described earlier (Listing 6).

Exported and Imported Symbols

The executable exports two symbols, environ and __progname, expected by libc, and imports puts and exit. In Listing 7, I wrap these declarations in some convenience macros.