Sections matter for linking and static analysis, while segments matter for loading and runtime execution. Sections group code, data, symbols, and relocation information so the binary can be built correctly. Segments, also called program headers, group those sections into memory-friendly chunks that the Linux loader can map efficiently at execution time.
Why sections and segments serve different jobs in an ELF file
ELF uses two different views of the same binary because the build pipeline and the runtime loader care about different things. Sections are the compiler and linker’s organisational units for code, data, relocation records, symbol tables, and other metadata. Segments are the loader’s view, describing how those contents should be mapped into memory with the right permissions and alignment.
That separation is not cosmetic. A file can contain many sections that never appear as standalone memory mappings, while a single loadable segment may combine multiple sections that need to sit together in the process image. Understanding that split explains why tools like readelf -S and readelf -l answer different questions.
For example, .text, .rodata, .data, .bss, and relocation sections help the linker decide layout, fix addresses, and preserve metadata for analysis. The program headers then group the loadable content into executable, readable, or writable ranges that the kernel can map efficiently at runtime.
How sections support linking and analysis
Sections are primarily about construction, transformation, and inspection. They let the linker place code and data, resolve symbols, apply relocations, and keep debug or metadata separate from the runtime image. That is why section names and section headers are valuable to reverse engineers, build systems, and static analysis tools even when the runtime loader ignores most of them.
Sections can also be stripped or compressed without changing the basic load behaviour of the executable, as long as the remaining loadable content stays consistent. This makes sections the right level for build-time optimisation, symbol management, and post-build inspection, but not the only source of truth for what the kernel will actually execute.
In practice, section headers are often absent or reduced in stripped binaries, while program headers remain essential. That is a useful reminder that static analysis and runtime execution are related but not interchangeable views of the same object file.
How segments shape loading and execution
Segments are driven by the program header table, which tells the loader what parts of the file to map, where to map them, and with which protections. A loadable segment may combine several sections so that executable code and read-only data share a memory layout that matches page boundaries and reduces wasted space.
This matter because the kernel does not load an ELF file section by section. It loads segments, applies alignment rules, and establishes the process image from those mappings. The loader therefore cares about runtime permissions, address ranges, and whether a segment is executable, writable, or read-only, not about the linker’s internal bookkeeping structure.
That is why sections can be useful for human understanding while segments determine whether the binary actually starts, where it lands in memory, and how its pages are protected during execution.
Practitioner Guidance
What to verify: When debugging an ELF binary, check the segment layout first if the issue is loading, mapping, permissions, or crash-at-start behaviour; check sections first if the issue is symbol resolution, relocation, or build output consistency. A binary can look correct at the section level and still fail because its program headers, alignment, or permissions are wrong.
Common mistake: Treating section names as if they describe runtime memory directly. They usually do not. The safer habit is to use section headers for build-time questions and program headers for execution-time questions.
Practitioner takeaway: ELF has two complementary truths, one for producing the binary and one for running it, and most confusion comes from reading the wrong one for the question at hand.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
