ELF Sections

The .text section contains the executable machine code instructions for a program. This is the read-only segment that the CPU or NPU fetches and executes. For NPU programming, this section may hold kernels compiled to the vendor's specific ISA.

• Key Property: Marked with the SHF_ALLOC and SHF_EXECINSTR flags.
• NPU Context: Vendor toolchains place optimized, intrinsic-heavy kernel code here.
• Example: The compiled binary for a matrix multiplication kernel optimized for a specific NPU tensor core.

These sections manage a program's static and global variables.

• .data section: Contains initialized static/global data (e.g., int x = 5;). It is read-write and occupies space in the binary.
• .bss section (Block Started by Symbol): Holds uninitialized static/global data (e.g., int buffer[1000];). It is read-write but occupies no space in the binary file, only a size descriptor, reducing file size. The loader allocates and zero-initializes this memory at runtime.

NPU Context: Pre-allocated weight tensors or constant lookup tables may reside in .data, while large scratchpad buffers may be declared in .bss.

The .rodata section stores constant, immutable data used by the program.

• Contents: String literals, global constants, jump tables, and switch-case data.
• Key Property: Marked as SHF_ALLOC (needs memory) but not writable (SHF_WRITE is false).
• NPU Context: Often holds quantization scales, bias constants, or activation lookup tables that kernels read during execution. Placing this data in .rodata allows for potential caching in the NPU's constant memory hierarchy.

These sections form the program's symbol table, essential for linking and debugging.

• .symtab (Symbol Table): An array of Elf64_Sym structures defining all symbols (functions, variables) – their names, binding (local/global), type, and associated section.
• .strtab (String Table): Holds the null-terminated string names for the symbols in .symtab. The .symtab entries contain offsets into this table.

Critical Role: The linker uses .symtab to resolve references between object files. For NPU binaries, this includes kernel function names exposed to the host CPU driver via the driver API.

Relocation sections provide instructions to the linker or dynamic loader on how to adjust symbolic references in the code once final memory addresses are known.

• Format: .rel.* contains entries with just an offset and symbol index. .rela.* adds an explicit addend.
• Process: When linking, the linker reads these sections and patches the actual bytes in sections like .text or .data with correct addresses.

NPU Context: Vital when a kernel compiled for an NPU references a global variable whose address isn't known until the final executable is linked. The vendor toolchain generates these entries.

These metadata sections describe the ELF file itself.

• .shstrtab (Section Header String Table): Contains the null-terminated names of all sections (e.g., ".text", ".data"). The section header table references this.
• Section Header Table: An array of Elf64_Shdr structures, one for every section in the file, including those describing other sections. Each header defines a section's name (as an index into .shstrtab), type, flags, address, offset, and size.

System Tool Dependency: Tools like readelf, objdump, and the linker itself rely entirely on these structures to parse the binary.

A data structure within an ELF file that describes a segment, which is a contiguous block of the executable image loaded into memory by the operating system loader. While sections (.text, .data) are used by the linker for organization, segments (LOAD, DYNAMIC) are used by the loader for execution.

• A single segment (e.g., a LOAD segment) typically contains multiple sections (e.g., .text and .rodata).
• Defines memory permissions: Read, Write, Execute (RWX).
• Essential for understanding the runtime memory layout of a process.

A section containing metadata that maps symbolic names (e.g., function and variable names) to their addresses or other information.

• .symtab: The static symbol table, used by linkers and debuggers. Can be stripped to reduce file size.
• .dynsym: The dynamic symbol table, required for runtime linking (e.g., using shared libraries). Contains a subset of symbols needed for dynamic resolution.
• Entries include symbol name, value (address), size, type (FUNC, OBJECT), and binding (LOCAL, GLOBAL).

A section that instructs the linker or dynamic loader how to patch addresses in the code or data after the final load address is known.

• Contains relocation entries specifying an offset within a section and a relocation type (e.g., R_X86_64_PC32).
• Corrects absolute addresses and position-independent code (PIC) references.
• Critical for shared library (.so) creation and loading, as the final load address is unknown at compile time.

A special section used by executables and shared libraries that require runtime linking. It acts as a "table of contents" for the dynamic linker.

• Contains an array of tags (e.g., DT_NEEDED for required libraries, DT_SYMTAB for the dynamic symbol table, DT_STRTAB for string table).
• Points to other essential sections like .dynsym, .dynstr, and .rela.dyn.
• The presence of this section marks a binary as dynamically linked.

Sections containing null-terminated strings referenced by other structures in the ELF file.

• .shstrtab: The section header string table holds the names of the sections themselves.
• .strtab: The string table for symbols in .symtab.
• .dynstr: The string table for dynamic symbols in .dynsym.
• These sections enable efficient storage of variable-length strings by using offsets as references, saving space.

An array of fixed-size section header structures located at the end of the ELF file. It is the primary directory for all sections.

• Each entry describes one section: its name (as an index into .shstrtab), type (e.g., PROGBITS, SYMTAB), flags (e.g., ALLOC, EXECINSTR), virtual address, file offset, and size.
• The e_shoff field in the ELF header points to the start of this table.
• A program can have zero sections (possible in a kernel image) but must have a section header table for linking.