Prerequisites

Before reading this lecture you should be comfortable with:

• Basic C programming (pointers, variables, functions)
• What a process is and how the OS loads a program
• Elementary understanding of memory addresses (virtual vs physical is a plus)

No kernel-level experience is required. This lecture is beginner-friendly and part of the free Linux kernel development course at EmbeddedPathashala.

1. Text Segment (Code Segment) — r-x

The text segment holds the compiled machine instructions of your program — what the CPU actually executes. It is marked read and execute only (r-x). Writing to this region is forbidden, which prevents accidental or malicious modification of running code.

This segment is static — its size is fixed at program load time and does not change during execution. On Linux 6.x, the kernel uses W^X (write XOR execute) policy: a memory page can be either writable or executable, never both simultaneously. This is enforced at the hardware level via the CPU’s NX (No-Execute) bit and is a crucial Linux kernel security feature.

When multiple processes run the same binary (for example, 10 shell instances), the kernel maps the same physical pages of the text segment into each process’s VAS. The code is shared in RAM but appears private to each process through the MMU’s page tables.

cat /proc/$$/maps | grep -E " r-xp "

2. Data Segments — rw-

The data segment stores global and static variables declared in your C program. It is read-write (rw-) because these variables need to be modified at runtime. Internally, it splits into two sub-regions:

/* Examples of data segment variables in C */

int global_init   = 42;          /* .data section  -- initialized  */
int global_uninit;                /* .bss  section  -- zeroed by OS */
static int module_counter = 0;   /* .data section  -- static       */

int main(void) {
    static int call_count;        /* .bss  -- static local, zeroed  */
    /* ... */
    return 0;
}

3. Heap Segment — Dynamic Memory (rw-)

The heap is where dynamically allocated memory lives — memory you request at runtime using malloc(), calloc(), realloc() or the C++ new operator. Unlike the text and data segments, the heap is dynamic: it can grow or shrink as the program allocates and frees memory.

The boundary between the heap and the unmapped region above it is called the program break. The classic brk() and sbrk() system calls move this break upward (to allocate more heap) or downward (to release it). The glibc malloc() implementation calls these internally on your behalf.

However, there is an important detail in modern Linux (including Linux 6.x):

#include <stdlib.h>
#include <stdio.h>

int main(void)
{
    /* Small: comes from heap segment (brk) */
    char *small = malloc(4096);   /* 4 KB -- from heap */

    /* Large: kernel creates a NEW anonymous mmap region */
    char *large = malloc(1024 * 1024);  /* 1 MB -- anonymous mmap */

    printf("small ptr : %p\n", small);
    printf("large ptr : %p\n", large);

    /* Inspect: cat /proc/<pid>/maps while sleeping */

    free(large);   /* mmap region is released back to OS immediately */
    free(small);   /* heap shrinks only when brk() is called */
    return 0;
}

4. Library Mappings — Shared Libraries (r-x / rw-)

Every modern Linux program uses shared libraries — the most fundamental being the C library (glibc, libc.so.6). These libraries are not copied into your binary at compile time (that would be static linking). Instead, the dynamic linker/loader (ld.so) maps them into the process VAS at runtime, right after execve() starts the process.

Each shared library gets two separate mappings in the process VAS:

• Text mapping (r-x): The library’s compiled code. Shared in physical RAM across all processes using that library — huge memory saving.
• Data mapping (rw-): The library’s global/static variables. Each process gets its own copy via Copy-On-Write (COW), so one process cannot affect another’s library state.

# See all library mappings of the bash shell:
cat /proc/$(pgrep -n bash)/maps

# Typical output (abbreviated):
# 7f2a1c000000-7f2a1c200000 r-xp  libc.so.6   <-- libc text
# 7f2a1c200000-7f2a1c400000 ---p  libc.so.6   <-- guard (no access)
# 7f2a1c400000-7f2a1c404000 r--p  libc.so.6   <-- libc read-only data
# 7f2a1c404000-7f2a1c406000 rw-p  libc.so.6   <-- libc writable data

5. Stack Segment — Function Call Machinery (rw-)

The stack is the memory region that implements your programming language’s function-call mechanism. Every time a function is called, the CPU allocates a stack frame for it. This frame holds:

• The local variables declared inside the function
• The function arguments (parameters)
• The return address — where to go after the function finishes
• Saved registers (CPU state preservation)

When the function returns, its stack frame is destroyed instantly — the Stack Pointer (SP) register is just moved back. This is why returning a pointer to a local variable is a bug in C: the memory is “gone” once the function returns.

Frequently Asked Questions

Authoritative References

• Linux Kernel Memory Management Documentation (kernel.org)
• proc(5) man page — /proc/<pid>/maps format (man7.org)
• mmap(2) man page (man7.org)
• glibc malloc tunables — MMAP_THRESHOLD (sourceware.org)