Operating SystemsMemory Management Fundamentals

Linkers and Loaders

LevelIntermediate

Duration90 mins

TopicMemory Management Fundamentals

2 / 5

Object Files

The Universal Currency of Compiled Code

When the assembler completes its work, it produces an object file—a structured container holding machine code, data, metadata, and instructions for the linker. Object files are the lingua franca of compiled programming: they provide a standardized format that allows code compiled from different languages, by different compilers, at different times, to be combined into a single executable.

Understanding object file internals is not merely academic curiosity. This knowledge is essential for:

Debugging — Tools like gdb, objdump, and readelf expose object file structures
Performance analysis — Understanding sections reveals memory layout
Security — Malware analysis and binary hardening depend on object file knowledge
System programming — Writing linkers, loaders, and operating systems
Interoperability — Linking libraries from different languages

What You Will Learn

By the end of this page, you will understand object file formats (ELF, COFF, Mach-O), their internal structure, sections, symbol tables, relocation entries, and how these components enable linking and loading. You'll be able to analyze object files using standard tools.

Object File Formats

Different operating systems use different object file formats, though the core concepts are remarkably similar. The three dominant formats are:

ELF (Executable and Linkable Format)

Used by Linux, BSD, Solaris, and most Unix systems
Standardized by the System V ABI
Used for object files, shared libraries, and executables
Highly flexible with extensible section types

COFF (Common Object File Format)

Originally designed for Unix System V
Extended for Windows as PE/COFF (Portable Executable)
Used for .obj, .exe, and .dll files on Windows
Simpler structure than ELF

Mach-O (Mach Object)

Used by macOS, iOS, watchOS, and tvOS
Descended from Mach kernel object format
Used for .o, executables, and .dylib (dynamic libraries)
Supports universal (fat) binaries containing multiple architectures

Object File Format Comparison
Format	Platform	Object Extension	Executable	Dynamic Library
ELF	Linux, BSD, Solaris	`.o`	No extension	`.so`
PE/COFF	Windows	`.obj`	`.exe`	`.dll`
Mach-O	macOS, iOS	`.o`	No extension	`.dylib`

Why ELF matters most:

We'll focus primarily on ELF because:

It's the most widely used format in OS development and systems programming
It's extensively documented and well-understood
Its concepts translate directly to other formats
Linux, the dominant server OS, uses ELF exclusively

The principles we explore apply universally—COFF and Mach-O have analogous structures with different terminology.

Historical Context

ELF was designed in the late 1980s as part of System V Release 4 to replace older formats like a.out (Assembler OUTput). Its name reflects its dual purpose: the same format serves both 'Executable' (ready to run) and 'Linkable' (ready for linking) roles.

ELF File Structure Overview

An ELF file consists of several distinct parts organized hierarchically:

ELF Header — File identification and metadata at the very beginning
Program Header Table — Describes segments for execution (optional in object files)
Sections — The actual content: code, data, symbols, relocations
Section Header Table — Describes each section's properties and location

The key insight is that ELF provides two views of the same file:

Linking view (Section Header Table): Used by the linker to combine object files
Execution view (Program Header Table): Used by the loader to create a process

Converting Mermaid diagram...

Viewing ELF Header (readelf -h)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
$ readelf -h hello.o
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          528 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           64 (bytes)
  Number of section headers:         13
  Section header string table index: 12

Key fields in the ELF header:

Magic number (0x7f ELF): Identifies the file as ELF
Class: ELF32 or ELF64 (32-bit or 64-bit addresses)
Data encoding: Little or big endian
Type: REL (relocatable), EXEC (executable), DYN (shared object)
Machine: Target architecture (x86-64, ARM, RISC-V, etc.)
Entry point: Starting address for executables (0 for object files)
Section header table offset: Where to find section descriptions

Core Sections: Code and Data

ELF files are divided into sections—contiguous chunks of data with specific purposes. Understanding the standard sections is essential for comprehending program memory layout.

Text Section (.text)

The .text section contains executable machine code—the actual instructions the CPU will execute. Key characteristics:

Read-only and executable permissions
Contains compiled functions
May be shared across multiple process instances (memory efficiency)
Protected from modification at runtime (security)

Viewing .text Section
1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ objdump -d hello.o
 
hello.o:     file format elf64-x86-64
 
Disassembly of section .text:
 
0000000000000000 <main>:
   0:   55                      push   %rbp
   1:   48 89 e5                mov    %rsp,%rbp
   4:   48 8d 3d 00 00 00 00    lea    0x0(%rip),%rdi
   b:   e8 00 00 00 00          call   10 <main+0x10>
  10:   b8 00 00 00 00          mov    $0x0,%eax
  15:   5d                      pop    %rbp
  16:   c3                      ret

Data Section (.data)

The .data section contains initialized global and static variables. These are variables with explicit initial values that persist for the program's lifetime.

Variables in .data
1
2
3
4
5
6
7
8
9
// These go in .data section
int global_count = 42;           // Initialized global
static double pi = 3.14159;      // Initialized static
 
int main() {
    static int call_count = 0;   // Initialized local static
    call_count++;
    return call_count;
}

BSS Section (.bss)

The .bss section (Block Started by Symbol) contains uninitialized global and static variables. The key insight: .bss doesn't store the actual zeros—it just records how many bytes are needed. This saves file space.

BSS optimization: A file with 1MB of uninitialized globals doesn't need 1MB of zeros in the object file. The .bss section header simply says "reserve 1MB at runtime."

Variables in .bss
1
2
3
4
// These go in .bss section (no space in file, zeroed at load)
int uninitialized_counter;       // Implicitly zero
static char buffer[4096];        // 4KB reserved, not stored
int zero_initialized = 0;        // May go in .bss (compiler choice)

Read-Only Data Section (.rodata)

The .rodata section contains constant data that should never be modified:

String literals
Constant global variables (const)
Jump tables for switch statements
Floating-point constants

Placing data in .rodata enables the memory to be mapped read-only, catching accidental writes and enabling sharing.

Section Summary
Section	Contents	In File?	Runtime Permissions
`.text`	Machine code	Yes	Read + Execute
`.data`	Initialized globals/statics	Yes	Read + Write
`.bss`	Uninitialized globals/statics	No (size only)	Read + Write
`.rodata`	Constants, string literals	Yes	Read only

Memory Layout Visualization

Use size command to see section sizes: size hello.o. This shows text, data, and bss sizes—essential for understanding program memory footprint and diagnosing binary bloat.

Symbol Tables: The Naming Registry

The symbol table is arguably the most important metadata structure in an object file. It's the registry of all named entities—functions, global variables, constants—that either:

Define something (provide an implementation/storage)
Reference something (use something defined elsewhere)

Symbol tables enable separate compilation: each source file is compiled independently, and the linker uses symbol tables to connect references to definitions across files.

Symbol Table Entry Structure (Elf64_Sym)
1
2
3
4
5
6
7
8
9
10
11
12
13
// ELF64 Symbol Table Entry (24 bytes each)
typedef struct {
    Elf64_Word    st_name;     // String table offset for name
    unsigned char st_info;     // Type and binding attributes
    unsigned char st_other;    // Visibility
    Elf64_Half    st_shndx;    // Section index (where defined)
    Elf64_Addr    st_value;    // Address or offset
    Elf64_Xword   st_size;     // Size of the symbol
} Elf64_Sym;
 
// st_info encodes both type and binding:
// Type: NOTYPE, OBJECT (data), FUNC, SECTION, FILE
// Binding: LOCAL, GLOBAL, WEAK

Symbol Binding

Binding determines visibility and linkage behavior:

LOCAL: Visible only within this object file (like static in C)
GLOBAL: Visible to all object files; only one definition allowed
WEAK: Like global, but can be overridden by a global definition

Weak symbols are powerful for providing default implementations that users can override:

Weak Symbol Example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// library.c - Provides weak default
__attribute__((weak)) void error_handler(const char* msg) {
    fprintf(stderr, "Error: %s
", msg);
    exit(1);
}
 
// user_code.c - Can override with strong symbol
void error_handler(const char* msg) {
    // Custom error handling
    log_to_file(msg);
    attempt_recovery();
}
 
// If user doesn't define error_handler, weak default is used
// If user defines it, their version wins

Examining Symbol Table (readelf -s)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$ readelf -s example.o
 
Symbol table '.symtab' contains 12 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS example.c
     2: 0000000000000000     0 SECTION LOCAL  DEFAULT    1 .text
     3: 0000000000000000     4 OBJECT  LOCAL  DEFAULT    3 local_static
     4: 0000000000000000    28 FUNC    GLOBAL DEFAULT    1 main
     5: 0000000000000000     4 OBJECT  GLOBAL DEFAULT    4 global_var
     6: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND printf
     7: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND external_func
 
# Ndx column meanings:
# UND = Undefined (external reference)
# ABS = Absolute (not associated with section)
# Number = Section index where symbol is defined

String Tables

Symbol names aren't stored in the symbol table entries directly. Instead, st_name is an offset into a string table (.strtab). The string table is simply a sequence of null-terminated strings. This design:

Allows variable-length names without fixed entry sizes
Enables string sharing (duplicate names use same offset)
Separates fixed-size structures from variable-size data

Undefined Symbols Must Be Resolved

Every undefined symbol (UND) must be resolved during linking. If the linker can't find a definition, you get the dreaded 'undefined reference' error. Common causes: missing library, typo in function name, or forgetting to link an object file.

Relocation Entries: Deferred Address Resolution

Relocation entries are the linker's instructions for fixing addresses. When code references a symbol whose address isn't yet known—an external function, a global variable, or even code in the same file at an undetermined location—the assembler generates a relocation entry.

Each relocation entry tells the linker:

Where: The location in the code that needs patching
What: Which symbol is being referenced
How: The calculation to compute the final address

Relocation Entry Structure (Elf64_Rela)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// ELF64 Relocation Entry with Addend (24 bytes each)
typedef struct {
    Elf64_Addr    r_offset;    // Where to apply relocation
    Elf64_Xword   r_info;      // Symbol index and relocation type
    Elf64_Sxword  r_addend;    // Constant addend for calculation
} Elf64_Rela;
 
// r_info encodes symbol index and type:
// Symbol index: upper 32 bits
// Relocation type: lower 32 bits
 
// Common x86-64 relocation types:
// R_X86_64_PC32    : 32-bit PC-relative
// R_X86_64_PLT32   : 32-bit PLT-relative (for function calls)
// R_X86_64_64      : 64-bit absolute address
// R_X86_64_GOTPCREL: 32-bit PC-relative to GOT entry

Relocation Types

The relocation type specifies how to compute the final address. Different types exist because:

Absolute vs. PC-relative: Direct address or offset from current position
Size differences: 32-bit or 64-bit values
Dynamic linking needs: PLT/GOT for position-independent code

PC-relative relocations are crucial for position-independent code (PIC). Instead of storing absolute addresses, code uses offsets from the current instruction pointer. This allows code to work regardless of where it's loaded in memory.

Viewing Relocations (readelf -r)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
$ readelf -r example.o
 
Relocation section '.rela.text' at offset 0x1d8 contains 3 entries:
  Offset          Info           Type           Sym.Value    Sym.Name+Addend
000000000007  000500000002 R_X86_64_PC32     0000000000000000 .rodata - 4
00000000000c  000b00000004 R_X86_64_PLT32    0000000000000000 printf - 4
000000000015  000c00000004 R_X86_64_PLT32    0000000000000000 external_func - 4
 
# Interpretation:
# At offset 0x07: reference to .rodata (string constant)
# At offset 0x0c: call to printf via PLT
# At offset 0x15: call to external_func via PLT
 
# The -4 addend compensates for x86-64 instruction encoding
# (the relocation target is computed from the *end* of the instruction)

How the Linker Applies Relocations

When the linker processes relocations:

Assign final addresses: Determine where each section will be loaded
Resolve symbols: Look up the final address of each referenced symbol
Calculate values: Apply the relocation formula (varies by type)
Patch the code: Write the computed value to the specified offset

For a PC-relative relocation (R_X86_64_PC32):

final_value = symbol_address + addend - relocation_offset

This gives the distance from the current instruction to the target—exactly what a relative jump or call needs.

Relocations Enable Flexibility

The relocation mechanism is why you can compile code without knowing where it will be loaded. The linker and loader handle address resolution. This is fundamental to modern operating systems, shared libraries, and ASLR (Address Space Layout Randomization) for security.

Additional Sections: Debugging and More

Beyond the core sections, object files contain numerous auxiliary sections for debugging, exception handling, and other purposes:

Debug Sections (DWARF Format)

When compiled with -g, the compiler generates DWARF debugging information in sections like:

.debug_info: Type information, variable locations
.debug_line: Source line to address mapping
.debug_abbrev: Abbreviations for compact encoding
.debug_str: Debug string table
.debug_frame: Call frame information for stack unwinding

Viewing Section Headers (readelf -S)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
$ readelf -S example.o
There are 14 section headers, starting at offset 0x390:
 
Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .text             PROGBITS         0000000000000000  00000040
       0000000000000017  0000000000000000  AX       0     0     1
  [ 2] .rela.text        RELA             0000000000000000  00000280
       0000000000000048  0000000000000018   I      11     1     8
  [ 3] .data             PROGBITS         0000000000000000  00000058
       0000000000000004  0000000000000000  WA       0     0     4
  [ 4] .bss              NOBITS           0000000000000000  0000005c
       0000000000000004  0000000000000000  WA       0     0     4
  [ 5] .rodata           PROGBITS         0000000000000000  0000005c
       000000000000000e  0000000000000000   A       0     0     1
  [ 6] .comment          PROGBITS         0000000000000000  0000006a
       0000000000000013  0000000000000001  MS       0     0     1
  [ 7] .note.GNU-stack   PROGBITS         0000000000000000  0000007d
       0000000000000000  0000000000000000           0     0     1
 
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), T (TLS)

Exception Handling Sections

For languages with exception support (C++, Rust), special sections enable stack unwinding:

.eh_frame: Exception handling frame information (runtime unwinding)
.eh_frame_hdr: Lookup table for .eh_frame
.gcc_except_table: Language-specific exception tables

Other Important Sections

.note.GNU-stack: Indicates whether the stack should be executable (security)
.comment: Compiler version string
.init_array/.fini_array: Constructor/destructor function pointers
.got/.plt: Global Offset Table and Procedure Linkage Table (dynamic linking)

Common ELF Sections Reference
Section	Purpose	Loaded?
`.text`	Executable code	Yes
`.rodata`	Read-only data, string literals	Yes
`.data`	Initialized read-write data	Yes
`.bss`	Uninitialized data (zeroed)	Yes (as zeros)
`.symtab`	Symbol table	No (stripped in release)
`.strtab`	Symbol name strings	No (stripped in release)
`.rela.*`	Relocation entries	No (consumed by linker)
`.debug_*`	Debug information	No (stripped in release)
`.eh_frame`	Exception handling	Yes

Stripping Symbols

Production executables often remove debug symbols and symbol tables using strip. This reduces file size and provides some obfuscation. However, .dynsym (dynamic symbol table) must be preserved for shared library function calls to work.

Object File Analysis Tools

Mastering object file analysis tools is essential for systems programming, debugging, and security research. Here's your toolkit:

readelf (ELF-specific)

The Swiss Army knife for ELF files. Platform-specific but comprehensive:

Essential readelf Commands
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# File header
readelf -h binary
 
# Section headers
readelf -S binary
 
# Symbol table
readelf -s binary
 
# Relocations
readelf -r binary
 
# Program headers (segments)
readelf -l binary
 
# Dynamic section (shared libraries)
readelf -d binary
 
# All information
readelf -a binary

objdump (Cross-platform)

Disassembler and object file dumper. Works with various formats:

Essential objdump Commands
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# Disassemble .text section
objdump -d binary
 
# Disassemble with source (if debug info available)
objdump -S binary
 
# All headers
objdump -x binary
 
# Section contents in hex
objdump -s binary
 
# Disassemble all sections
objdump -D binary
 
# Display relocations
objdump -r binary

nm (Symbol lister)

Compact symbol table viewer:

nm Usage
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# List all symbols
nm binary
 
# Include undefined symbols
nm -u binary
 
# Show symbol sizes
nm -S binary
 
# Demangle C++ names
nm -C binary
 
# Sort by size (find large symbols)
nm -S --size-sort binary

Tool Selection Guide

•readelf — Best for detailed ELF structure analysis
•objdump — Best for disassembly and cross-platform work
•nm — Best for quick symbol table inspection
•size — Best for section size summary
•strings — Find embedded strings in binaries
•hexdump/xxd — Raw binary inspection

Summary: Object File Mastery

Object files are the critical intermediaries between compilation and execution. Their structured format enables the modular compilation and linking model that makes large software development practical.

Key Takeaways

•ELF is the dominant format on Unix-like systems, with PE/COFF on Windows and Mach-O on macOS serving equivalent roles.
•Sections organize content by type: .text for code, .data/.bss for variables, .rodata for constants, plus many auxiliary sections.
•Symbol tables are the naming registry, containing all defined and referenced identifiers with their types, bindings, and locations.
•Relocation entries defer address resolution, enabling separate compilation by letting the linker fix addresses at link time.
•Debug sections (DWARF) provide source-level debugging capabilities without affecting runtime behavior.
•Analysis tools like readelf, objdump, and nm are essential for understanding, debugging, and reverse engineering binaries.

What's next:

With a solid understanding of object files, we're ready to explore linking—the process that combines multiple object files into a single executable. The next page covers static and dynamic linking in detail, explaining how symbols are resolved and how shared libraries work.

Page Complete

You now understand object file structure at a deep level—ELF format, sections, symbol tables, and relocations. This knowledge is foundational for understanding linking, loading, and ultimately how the operating system creates and manages processes.

2 / 5

Loading learning content...

Operating SystemsMemory Management Fundamentals

Linkers and Loaders

LevelIntermediate

Duration90 mins

TopicMemory Management Fundamentals

2 / 5

Object Files

The Universal Currency of Compiled Code

Understanding object file internals is not merely academic curiosity. This knowledge is essential for:

Debugging — Tools like gdb, objdump, and readelf expose object file structures
Performance analysis — Understanding sections reveals memory layout
Security — Malware analysis and binary hardening depend on object file knowledge
System programming — Writing linkers, loaders, and operating systems
Interoperability — Linking libraries from different languages

What You Will Learn

Object File Formats

Different operating systems use different object file formats, though the core concepts are remarkably similar. The three dominant formats are:

ELF (Executable and Linkable Format)

Used by Linux, BSD, Solaris, and most Unix systems
Standardized by the System V ABI
Used for object files, shared libraries, and executables
Highly flexible with extensible section types

COFF (Common Object File Format)

Originally designed for Unix System V
Extended for Windows as PE/COFF (Portable Executable)
Used for .obj, .exe, and .dll files on Windows
Simpler structure than ELF

Mach-O (Mach Object)

Used by macOS, iOS, watchOS, and tvOS
Descended from Mach kernel object format
Used for .o, executables, and .dylib (dynamic libraries)
Supports universal (fat) binaries containing multiple architectures

Object File Format Comparison
Format	Platform	Object Extension	Executable	Dynamic Library
ELF	Linux, BSD, Solaris	`.o`	No extension	`.so`
PE/COFF	Windows	`.obj`	`.exe`	`.dll`
Mach-O	macOS, iOS	`.o`	No extension	`.dylib`

Why ELF matters most:

We'll focus primarily on ELF because:

It's the most widely used format in OS development and systems programming
It's extensively documented and well-understood
Its concepts translate directly to other formats
Linux, the dominant server OS, uses ELF exclusively

The principles we explore apply universally—COFF and Mach-O have analogous structures with different terminology.

Historical Context

ELF File Structure Overview

An ELF file consists of several distinct parts organized hierarchically:

ELF Header — File identification and metadata at the very beginning
Program Header Table — Describes segments for execution (optional in object files)
Sections — The actual content: code, data, symbols, relocations
Section Header Table — Describes each section's properties and location

The key insight is that ELF provides two views of the same file:

Linking view (Section Header Table): Used by the linker to combine object files
Execution view (Program Header Table): Used by the loader to create a process

Converting Mermaid diagram...

Viewing ELF Header (readelf -h)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
$ readelf -h hello.o
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          528 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           64 (bytes)
  Number of section headers:         13
  Section header string table index: 12

Key fields in the ELF header:

Magic number (0x7f ELF): Identifies the file as ELF
Class: ELF32 or ELF64 (32-bit or 64-bit addresses)
Data encoding: Little or big endian
Type: REL (relocatable), EXEC (executable), DYN (shared object)
Machine: Target architecture (x86-64, ARM, RISC-V, etc.)
Entry point: Starting address for executables (0 for object files)
Section header table offset: Where to find section descriptions

Core Sections: Code and Data

ELF files are divided into sections—contiguous chunks of data with specific purposes. Understanding the standard sections is essential for comprehending program memory layout.

Text Section (.text)

The .text section contains executable machine code—the actual instructions the CPU will execute. Key characteristics:

Read-only and executable permissions
Contains compiled functions
May be shared across multiple process instances (memory efficiency)
Protected from modification at runtime (security)

Viewing .text Section
1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ objdump -d hello.o
 
hello.o:     file format elf64-x86-64
 
Disassembly of section .text:
 
0000000000000000 <main>:
   0:   55                      push   %rbp
   1:   48 89 e5                mov    %rsp,%rbp
   4:   48 8d 3d 00 00 00 00    lea    0x0(%rip),%rdi
   b:   e8 00 00 00 00          call   10 <main+0x10>
  10:   b8 00 00 00 00          mov    $0x0,%eax
  15:   5d                      pop    %rbp
  16:   c3                      ret

Data Section (.data)

The .data section contains initialized global and static variables. These are variables with explicit initial values that persist for the program's lifetime.

Variables in .data
1
2
3
4
5
6
7
8
9
// These go in .data section
int global_count = 42;           // Initialized global
static double pi = 3.14159;      // Initialized static
 
int main() {
    static int call_count = 0;   // Initialized local static
    call_count++;
    return call_count;
}

BSS Section (.bss)

BSS optimization: A file with 1MB of uninitialized globals doesn't need 1MB of zeros in the object file. The .bss section header simply says "reserve 1MB at runtime."

Variables in .bss
1
2
3
4
// These go in .bss section (no space in file, zeroed at load)
int uninitialized_counter;       // Implicitly zero
static char buffer[4096];        // 4KB reserved, not stored
int zero_initialized = 0;        // May go in .bss (compiler choice)

Read-Only Data Section (.rodata)

The .rodata section contains constant data that should never be modified:

String literals
Constant global variables (const)
Jump tables for switch statements
Floating-point constants

Placing data in .rodata enables the memory to be mapped read-only, catching accidental writes and enabling sharing.

Section Summary
Section	Contents	In File?	Runtime Permissions
`.text`	Machine code	Yes	Read + Execute
`.data`	Initialized globals/statics	Yes	Read + Write
`.bss`	Uninitialized globals/statics	No (size only)	Read + Write
`.rodata`	Constants, string literals	Yes	Read only

Memory Layout Visualization

Use size command to see section sizes: size hello.o. This shows text, data, and bss sizes—essential for understanding program memory footprint and diagnosing binary bloat.

Symbol Tables: The Naming Registry

The symbol table is arguably the most important metadata structure in an object file. It's the registry of all named entities—functions, global variables, constants—that either:

Define something (provide an implementation/storage)
Reference something (use something defined elsewhere)

Symbol tables enable separate compilation: each source file is compiled independently, and the linker uses symbol tables to connect references to definitions across files.

Symbol Table Entry Structure (Elf64_Sym)
1
2
3
4
5
6
7
8
9
10
11
12
13
// ELF64 Symbol Table Entry (24 bytes each)
typedef struct {
    Elf64_Word    st_name;     // String table offset for name
    unsigned char st_info;     // Type and binding attributes
    unsigned char st_other;    // Visibility
    Elf64_Half    st_shndx;    // Section index (where defined)
    Elf64_Addr    st_value;    // Address or offset
    Elf64_Xword   st_size;     // Size of the symbol
} Elf64_Sym;
 
// st_info encodes both type and binding:
// Type: NOTYPE, OBJECT (data), FUNC, SECTION, FILE
// Binding: LOCAL, GLOBAL, WEAK

Symbol Binding

Binding determines visibility and linkage behavior:

LOCAL: Visible only within this object file (like static in C)
GLOBAL: Visible to all object files; only one definition allowed
WEAK: Like global, but can be overridden by a global definition

Weak symbols are powerful for providing default implementations that users can override:

Weak Symbol Example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// library.c - Provides weak default
__attribute__((weak)) void error_handler(const char* msg) {
    fprintf(stderr, "Error: %s
", msg);
    exit(1);
}
 
// user_code.c - Can override with strong symbol
void error_handler(const char* msg) {
    // Custom error handling
    log_to_file(msg);
    attempt_recovery();
}
 
// If user doesn't define error_handler, weak default is used
// If user defines it, their version wins

Examining Symbol Table (readelf -s)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$ readelf -s example.o
 
Symbol table '.symtab' contains 12 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS example.c
     2: 0000000000000000     0 SECTION LOCAL  DEFAULT    1 .text
     3: 0000000000000000     4 OBJECT  LOCAL  DEFAULT    3 local_static
     4: 0000000000000000    28 FUNC    GLOBAL DEFAULT    1 main
     5: 0000000000000000     4 OBJECT  GLOBAL DEFAULT    4 global_var
     6: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND printf
     7: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND external_func
 
# Ndx column meanings:
# UND = Undefined (external reference)
# ABS = Absolute (not associated with section)
# Number = Section index where symbol is defined

String Tables

Allows variable-length names without fixed entry sizes
Enables string sharing (duplicate names use same offset)
Separates fixed-size structures from variable-size data

Undefined Symbols Must Be Resolved

Relocation Entries: Deferred Address Resolution

Each relocation entry tells the linker:

Where: The location in the code that needs patching
What: Which symbol is being referenced
How: The calculation to compute the final address

Relocation Entry Structure (Elf64_Rela)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// ELF64 Relocation Entry with Addend (24 bytes each)
typedef struct {
    Elf64_Addr    r_offset;    // Where to apply relocation
    Elf64_Xword   r_info;      // Symbol index and relocation type
    Elf64_Sxword  r_addend;    // Constant addend for calculation
} Elf64_Rela;
 
// r_info encodes symbol index and type:
// Symbol index: upper 32 bits
// Relocation type: lower 32 bits
 
// Common x86-64 relocation types:
// R_X86_64_PC32    : 32-bit PC-relative
// R_X86_64_PLT32   : 32-bit PLT-relative (for function calls)
// R_X86_64_64      : 64-bit absolute address
// R_X86_64_GOTPCREL: 32-bit PC-relative to GOT entry

Relocation Types

The relocation type specifies how to compute the final address. Different types exist because:

Absolute vs. PC-relative: Direct address or offset from current position
Size differences: 32-bit or 64-bit values
Dynamic linking needs: PLT/GOT for position-independent code

Viewing Relocations (readelf -r)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
$ readelf -r example.o
 
Relocation section '.rela.text' at offset 0x1d8 contains 3 entries:
  Offset          Info           Type           Sym.Value    Sym.Name+Addend
000000000007  000500000002 R_X86_64_PC32     0000000000000000 .rodata - 4
00000000000c  000b00000004 R_X86_64_PLT32    0000000000000000 printf - 4
000000000015  000c00000004 R_X86_64_PLT32    0000000000000000 external_func - 4
 
# Interpretation:
# At offset 0x07: reference to .rodata (string constant)
# At offset 0x0c: call to printf via PLT
# At offset 0x15: call to external_func via PLT
 
# The -4 addend compensates for x86-64 instruction encoding
# (the relocation target is computed from the *end* of the instruction)

How the Linker Applies Relocations

When the linker processes relocations:

Assign final addresses: Determine where each section will be loaded
Resolve symbols: Look up the final address of each referenced symbol
Calculate values: Apply the relocation formula (varies by type)
Patch the code: Write the computed value to the specified offset

For a PC-relative relocation (R_X86_64_PC32):

final_value = symbol_address + addend - relocation_offset

This gives the distance from the current instruction to the target—exactly what a relative jump or call needs.

Relocations Enable Flexibility

Additional Sections: Debugging and More

Beyond the core sections, object files contain numerous auxiliary sections for debugging, exception handling, and other purposes:

Debug Sections (DWARF Format)

When compiled with -g, the compiler generates DWARF debugging information in sections like:

.debug_info: Type information, variable locations
.debug_line: Source line to address mapping
.debug_abbrev: Abbreviations for compact encoding
.debug_str: Debug string table
.debug_frame: Call frame information for stack unwinding

Viewing Section Headers (readelf -S)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
$ readelf -S example.o
There are 14 section headers, starting at offset 0x390:
 
Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .text             PROGBITS         0000000000000000  00000040
       0000000000000017  0000000000000000  AX       0     0     1
  [ 2] .rela.text        RELA             0000000000000000  00000280
       0000000000000048  0000000000000018   I      11     1     8
  [ 3] .data             PROGBITS         0000000000000000  00000058
       0000000000000004  0000000000000000  WA       0     0     4
  [ 4] .bss              NOBITS           0000000000000000  0000005c
       0000000000000004  0000000000000000  WA       0     0     4
  [ 5] .rodata           PROGBITS         0000000000000000  0000005c
       000000000000000e  0000000000000000   A       0     0     1
  [ 6] .comment          PROGBITS         0000000000000000  0000006a
       0000000000000013  0000000000000001  MS       0     0     1
  [ 7] .note.GNU-stack   PROGBITS         0000000000000000  0000007d
       0000000000000000  0000000000000000           0     0     1
 
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), T (TLS)

Exception Handling Sections

For languages with exception support (C++, Rust), special sections enable stack unwinding:

.eh_frame: Exception handling frame information (runtime unwinding)
.eh_frame_hdr: Lookup table for .eh_frame
.gcc_except_table: Language-specific exception tables

Other Important Sections

.note.GNU-stack: Indicates whether the stack should be executable (security)
.comment: Compiler version string
.init_array/.fini_array: Constructor/destructor function pointers
.got/.plt: Global Offset Table and Procedure Linkage Table (dynamic linking)

Common ELF Sections Reference
Section	Purpose	Loaded?
`.text`	Executable code	Yes
`.rodata`	Read-only data, string literals	Yes
`.data`	Initialized read-write data	Yes
`.bss`	Uninitialized data (zeroed)	Yes (as zeros)
`.symtab`	Symbol table	No (stripped in release)
`.strtab`	Symbol name strings	No (stripped in release)
`.rela.*`	Relocation entries	No (consumed by linker)
`.debug_*`	Debug information	No (stripped in release)
`.eh_frame`	Exception handling	Yes

Stripping Symbols

Object File Analysis Tools

Mastering object file analysis tools is essential for systems programming, debugging, and security research. Here's your toolkit:

readelf (ELF-specific)

The Swiss Army knife for ELF files. Platform-specific but comprehensive:

Essential readelf Commands
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# File header
readelf -h binary
 
# Section headers
readelf -S binary
 
# Symbol table
readelf -s binary
 
# Relocations
readelf -r binary
 
# Program headers (segments)
readelf -l binary
 
# Dynamic section (shared libraries)
readelf -d binary
 
# All information
readelf -a binary

objdump (Cross-platform)

Disassembler and object file dumper. Works with various formats:

Essential objdump Commands
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# Disassemble .text section
objdump -d binary
 
# Disassemble with source (if debug info available)
objdump -S binary
 
# All headers
objdump -x binary
 
# Section contents in hex
objdump -s binary
 
# Disassemble all sections
objdump -D binary
 
# Display relocations
objdump -r binary

nm (Symbol lister)

Compact symbol table viewer:

nm Usage
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# List all symbols
nm binary
 
# Include undefined symbols
nm -u binary
 
# Show symbol sizes
nm -S binary
 
# Demangle C++ names
nm -C binary
 
# Sort by size (find large symbols)
nm -S --size-sort binary

Tool Selection Guide

•readelf — Best for detailed ELF structure analysis
•objdump — Best for disassembly and cross-platform work
•nm — Best for quick symbol table inspection
•size — Best for section size summary
•strings — Find embedded strings in binaries
•hexdump/xxd — Raw binary inspection

Summary: Object File Mastery

Key Takeaways

•ELF is the dominant format on Unix-like systems, with PE/COFF on Windows and Mach-O on macOS serving equivalent roles.
•Sections organize content by type: .text for code, .data/.bss for variables, .rodata for constants, plus many auxiliary sections.
•Symbol tables are the naming registry, containing all defined and referenced identifiers with their types, bindings, and locations.
•Relocation entries defer address resolution, enabling separate compilation by letting the linker fix addresses at link time.
•Debug sections (DWARF) provide source-level debugging capabilities without affecting runtime behavior.
•Analysis tools like readelf, objdump, and nm are essential for understanding, debugging, and reverse engineering binaries.

What's next:

Page Complete

2 / 5