CompilersLinkers & LoadersMedium

Parse and Understand Object File Formats (ELF)

Master the fundamental concepts of linkers & loaders through this focused micro-challenge.

~45 minutes Linkers & Loaders Ready to learn

Topic Overview

ELF and Object Files

Compilers emit object files (.o), not executables. ELF on Linux, Mach-O on macOS, COFF on Windows: all contain machine code, symbol tables, and relocation entries. readelf and LLVM's llvm-objdump are daily tools for backend engineers.

ELF Sections

.text holds code. .data and .bss hold initialized and zero-initialized data. .symtab lists symbols with binding (local/global/weak) and section index. .rela.text records fixup sites that the linker must patch.

c
Loading…

Relocations patch addresses the compiler could not fix
Symbols may be undefined until link time
Debug sections (.debug_info) map to source lines
Object files are the linker's input atoms

Connecting to real compilers

Production compilers embed this step inside a longer pipeline. GCC flows through cpp, cc1, assembly, and ld; Clang uses the driver, Sema, LLVM IR passes, and a target backend. LLVM bitcode, JVM bytecode, and WASM are other familiar IRs at the same layer. The exercise isolates one pass so you can test it alone before chaining it to the next stage.

Why for this exercise

You will parse and understand object file structure for ELF. This exercise asks you to read section headers, symbol tables, and relocation entries from a simple compiled object.

Implementation Task

Your Task

Write the core of readelf -h -S: decode an ELF object file's header and its section header table. ELF is the container format of every Linux object file, shared library and executable; understanding its layout is the first step toward writing a linker or loader.

Input

The raw bytes of one file as hexadecimal pairs separated by whitespace (16 per line, like xxd -p output). The file may be ELF64 or ELF32, little-endian.

What to decode

Identification (e_ident): bytes 0-3 must be 7f 45 4c 46 (\x7fELF); byte 4 is the class (1 = ELF32, 2 = ELF64); byte 5 is the data encoding (1 = little-endian).
Header fields: e_type at offset 16 (1 REL, 2 EXEC, 3 DYN, 4 CORE), e_machine at 18 (3 i386, 40 ARM, 62 x86-64, 183 AArch64, 243 RISC-V), e_entry at 24, e_shoff at 40 (ELF64) / 32 (ELF32), and e_shentsize, e_shnum, e_shstrndx at 58/60/62 (ELF64) or 46/48/50 (ELF32). Addresses and offsets are 8 bytes in ELF64, 4 in ELF32.
Section headers: e_shnum entries of e_shentsize bytes at e_shoff. In each: sh_name (offset into the section-name string table) at 0, sh_type at 4, sh_flags at 8, sh_offset at 24/16 and sh_size at 32/20 (ELF64/ELF32).
Section names come from the string table section with index e_shstrndx.

Output

c
Loading…

NAME is - when empty.
TYPE: NULL PROGBITS SYMTAB STRTAB RELA NOBITS REL DYNSYM for 0, 1, 2, 3, 4, 8, 9, 11, otherwise 0xHEX.
FLAGS: letters in this order for the set bits: W (0x1 write), A (0x2 alloc), X (0x4 exec), M (0x10 merge), S (0x20 strings), or -.
Numbers are lower-case hex without leading zeros.

If the magic bytes are wrong, print only error: not an ELF file.

Example

A one-function object file:

Input:

c
Loading…

Output:

c
Loading…

Requirements

Read fields with explicit little-endian byte assembly (don't cast the buffer to structs: class and alignment differ).
Branch on the class once, choosing field offsets and widths.

Hidden tests include an AArch64 object with M/S flags and a file that is not ELF.