Executable and Linkable Format (ELF)

The ELF Header is located at the start of the file and serves as a roadmap. It defines the file's fundamental properties, including:

• Magic Number: The initial bytes (0x7f 'E' 'L' 'F') that identify the file as ELF.
• Class: Specifies the architecture as 32-bit (ELFCLASS32) or 64-bit (ELFCLASS64).
• Data Encoding: Defines byte order as little-endian (ELFDATA2LSB) or big-endian (ELFDATA2MSB).
• Type: Identifies the file type: relocatable object (ET_REL), executable (ET_EXEC), shared object (ET_DYN), or core file (ET_CORE).
• Machine: Specifies the required CPU architecture (e.g., EM_X86_64 for x86-64).
• Entry Point: The virtual address where the system transfers control to start the program.
• Offsets: Pointers to the start of the Program Header Table and Section Header Table.

The Program Header Table is an array of program headers, essential for the operating system's loader. It describes segments—contiguous chunks of the file that are mapped into memory at runtime. Key segment types include:

• PT_LOAD: A loadable segment containing executable code (.text) or data (.data, .bss). A file typically has at least two: one for code (read-only, execute) and one for data (read-write).
• PT_DYNAMIC: Contains dynamic linking information, such as the location of the symbol table and relocation entries.
• PT_INTERP: Specifies the path to the program interpreter (e.g., /lib64/ld-linux-x86-64.so.2), which is the dynamic linker.
• PT_PHDR: Points to the program header table itself, useful for the loader. Each header defines the segment's virtual address (Vaddr), physical address (Paddr), file offset, size in memory (Memsz), size in file (Filesz), and permission flags (read, write, execute).

The Section Header Table is an array of section headers, primarily used by linkers and debugging tools. It describes sections—smaller, named blocks within segments that hold specific types of data. Common sections include:

• .text: The executable machine instructions.
• .data: Initialized global and static variables.
• .rodata: Read-only data, such as string literals.
• .bss: Block Started by Symbol; holds uninitialized global/static variables (occupies no space in the file, only size definition).
• .symtab: The symbol table, a list of functions and variables with their names, addresses, and sizes.
• .strtab: The string table holding null-terminated symbol names referenced by .symtab.
• .rela.text / .rela.data: Relocation entries containing information for the linker to adjust addresses in code/data.
• .dynamic: Contains dynamic linking information, mirroring the PT_DYNAMIC segment. While segments are for runtime execution, sections are for static analysis and linking.

A core concept in ELF is the distinction and mapping between sections and segments.

• Sections are defined in the Section Header Table. They are logical views of the file's contents used by the linker (ld) and tools like objdump and readelf. Their purpose is organization and static analysis.
• Segments are defined in the Program Header Table. They are runtime views used by the operating system loader to map parts of the file into memory. A segment is a container for one or more sections. The Mapping: When a program is executed, the loader reads the program headers. It ignores sections entirely. It maps each PT_LOAD segment from the file into memory at the specified virtual address. Multiple sections (like .text and .rodata) are packed into a single read-only, executable segment. The .data and .bss sections are packed into a single read-write segment. The strip command removes the section header table without affecting execution, proving segments are sufficient for the loader.

For executables that use shared libraries, ELF files contain extensive metadata for the dynamic linker. This is primarily housed in the PT_DYNAMIC segment (.dynamic section). Key data structures include:

• Dynamic Symbol Table (.dynsym): A subset of the full symbol table, containing only symbols needed for dynamic linking (e.g., printf from libc).
• Dynamic String Table (.dynstr): String names for the dynamic symbols.
• Global Offset Table (.got): A table of absolute addresses for global data. The Procedure Linkage Table (.plt), which contains stub code for function calls, interacts with the GOT to resolve external function addresses lazily at runtime.
• Relocation Tables (.rela.dyn, .rela.plt): Instructions for the dynamic linker to patch addresses in the GOT and PLT once the actual memory addresses of shared library functions are known.
• DT_NEEDED Entries: A list of required shared library names (e.g., libc.so.6).
• DT_RPATH/DT_RUNPATH: Directories to search for shared libraries. This metadata enables position-independent code (PIC) and the lazy binding optimization, which defers symbol resolution until the first call.

A suite of standard Unix tools allows developers to inspect and manipulate ELF files, which is critical for debugging and optimization in deployment pipelines.

• readelf: The primary tool for displaying comprehensive ELF information. Use readelf -h for the header, readelf -l for program headers (segments), and readelf -S for section headers.
• objdump: Powerful for disassembly and detailed section analysis. objdump -d disassembles the .text section, while objdump -x shows all headers.
• nm: Lists symbols from the symbol table (.symtab), showing their names, types, and virtual addresses.
• ldd: Lists the shared library dependencies of a dynamic executable by reading the DT_NEEDED entries.
• strip: Removes the symbol table (.symtab) and debugging sections to reduce file size for production deployment, without affecting the program headers needed for execution.
• patchelf: A utility to modify various ELF properties, such as changing the RPATH or interpreter path, which is useful for creating portable binaries.

ELF files containing a complete, ready-to-run program. The OS loader maps the segments defined in the program header table into memory and transfers control to the entry point.

• Key Sections: .text (code), .data (initialized data), .rodata (read-only data).
• Dynamic Linking: Most executables are dynamically linked, containing a .interp section pointing to the dynamic linker (e.g., /lib64/ld-linux-x86-64.so.2).
• Entry Point: The e_entry field in the ELF header specifies the virtual address where execution begins.

The output of a compiler (.o files), containing code and data but not yet a final executable. These files are inputs to the linker.

• Symbol Tables: Contain STT_NOTYPE, STT_OBJECT, and STT_FUNC symbols, many of which are unresolved (e.g., printf).
• Relocation Sections: Sections like .rela.text contain relocation entries that instruct the linker how to patch addresses once final memory locations are known.
• No Program Headers: Typically lack a program header table; the segment layout is the linker's responsibility.

Dynamically linked libraries (.so files) containing code intended to be shared among multiple processes. They are a hybrid of executable and relocatable features.

• Position-Independent Code (PIC): Code is compiled to be loaded at any virtual address, using a Global Offset Table (GOT) and Procedure Linkage Table (PLT) for addressing.
• Dynamic Section: Contains critical metadata for the runtime linker (DT_NEEDED, DT_SYMTAB, DT_HASH/DT_GNU_HASH).
• Symbol Visibility: Controls which functions are exported (STB_GLOBAL) or kept internal (STB_LOCAL or STV_HIDDEN).

ELF files generated by the kernel when a process terminates due to a fatal signal (e.g., SIGSEGV). They contain a snapshot of the process's address space and register state at the time of crash.

• Program Headers for Memory: Each PT_LOAD segment corresponds to a memory region (code, heap, stack) from the original process.
• Note Sections: Contain auxiliary information like the prstatus structure (register values) and prpsinfo (process name, command line).
• Debugging: Essential for post-mortem analysis with tools like gdb to diagnose crashes in production.

ELF is the standard format for Linux kernel images (vmlinux) and many bootloaders (e.g., GRUB2's core image). The bootloader or firmware parses the ELF headers to load segments into specific physical memory addresses.

• No Dynamic Linking: Kernel images are statically linked.
• Custom Sections: May contain architecture-specific sections (e.g., .init.text for initialization code that can be discarded after boot).
• Entry Point: For the kernel, the entry point is the start of architecture-specific assembly bootstrap code.

In embedded systems, ELF is the primary output of cross-compilation toolchains. The ELF file is used for debugging with symbols, while a raw binary (.bin) or Intel HEX file is extracted for flashing.

• Linker Scripts: Heavily used to define precise memory maps, placing .text in ROM and .data in RAM.
• No OS Loader: The program headers (PT_LOAD) are read by the flashing tool, not a runtime loader.
• Debugging: The ELF file, with its symbol table and debugging sections, is paired with the flashed binary for source-level debugging via JTAG/SWD.

An Application Binary Interface (ABI) is the low-level contract between an executable and the operating system or between different compiled modules. It defines the precise rules for:

• Calling conventions: How function arguments are passed (registers vs. stack) and values are returned.
• System call numbers: The mapping from library functions to kernel interrupts.
• Data representation: Size, alignment, and byte order of fundamental data types.
• Object file format: Often ELF itself, specifying how code and data are laid out. The ABI ensures binary compatibility; an ELF executable compiled for the Linux x86_64 ABI will not run on a system expecting the ARM ABI, even if the CPU architecture could theoretically execute the instructions.

Ahead-of-Time Compilation (AOT) is a strategy where source code or an intermediate representation is fully compiled into a native machine binary before execution. This is the traditional model for creating ELF executables and shared libraries (.so files).

Key characteristics include:

• Produces a standalone ELF binary containing machine code for a specific target CPU and ABI.
• All symbol addresses and relocations are resolved at compile/link time, not at runtime.
• Enables maximum optimization by the compiler (e.g., GCC, Clang) with full program view.
• Contrasts with Just-in-Time (JIT) compilation, which happens during runtime. In NPU contexts, AOT compilation of a neural network graph into a vendor-specific NPU binary is critical for deploying optimized, low-latency models.

Link-Time Optimization (LTO) is a compiler technique that postpones major optimization passes until the final linking stage. During compilation, modules are saved in an intermediate representation (IR) within the object files (e.g., in a special ELF section). The linker then merges all IR and performs whole-program optimizations.

Benefits for performance-critical deployment:

• Cross-module inlining: Functions from one .o file can be inlined into another.
• Dead code elimination: Removal of functions and data unused across the entire program.
• Inter-procedural constant propagation. This results in a more optimized final ELF executable or shared library, which is especially valuable for large applications and runtime libraries where modularity traditionally limits compiler insight.

Dynamic Linking is the process of resolving symbols and loading code from external shared libraries (ELF .so files) at runtime, rather than at build time. The main ELF executable contains a PT_INTERP program header pointing to the dynamic linker (e.g., /lib64/ld-linux-x86-64.so.2) and a .dynamic section listing required libraries.

Runtime process involves:

1. The kernel loads the ELF executable and the dynamic linker.
2. The dynamic linker loads the listed .so files, performing relocation to resolve absolute addresses.
3. Lazy binding (via the Procedure Linkage Table, PLT) often defers resolution of individual function addresses until first call for speed. This enables code sharing, smaller binaries, and library updates without recompiling every dependent application.

DWARF is a standardized debugging data format, stored in specific sections (e.g., .debug_info, .debug_line) within an ELF file. It provides a comprehensive map between the executable machine code and the original source code, enabling symbolic debugging.

Information encoded in DWARF includes:

• Variable locations: Where a local variable is stored (register or stack offset) for each line of code.
• Data type descriptions: Structures, classes, and their members.
• Source file and line mapping: Which machine instruction corresponds to which source line.
• Call frame information: For unwinding the stack during exceptions. Tools like GDB and LLDB read the DWARF data from the ELF file to allow developers to step through code, inspect variables, and analyze crashes. Stripping these sections reduces file size but eliminates debug capability.

An executable stack is a memory region with both write and execute permissions, a historical feature that posed major security risks for buffer overflows. The ELF format controls this via the PT_GNU_STACK program header.

Modern hardening practices:

• No-execute (NX) bit: The linker marks the stack as non-executable (-z noexecstack), which is signaled in the ELF header. The kernel enforces this, preventing code injection attacks from succeeding.
• Position-Independent Executable (PIE): The entire executable is compiled as a shared library, allowing Address Space Layout Randomization (ASLR) to be fully effective, making memory addresses unpredictable.
• Relocation Read-Only (RELRO): Makes the Global Offset Table (GOT) read-only after dynamic linking, preventing GOT overwrite attacks. These security features are flags and metadata within the ELF file that instruct the operating system loader on how to apply modern exploit mitigations.