Memory Map In C

A typical memory representation of C program consists of following sections.
1. Text segment

2. Initialized data segment
3. Uninitialized data segment
4. Stack
5. Heap

A typical memory layout of a running process
1. Text Segment:

A text segment , also known as a code segment or simply as text, is one of the sections of a program in an object file or in memory, which contains executable instructions.

As a memory region, a text segment may be placed below the heap or stack in order to prevent heaps and stack overflows from overwriting it.
Usually, the text segment is sharable so that only a single copy needs to be in memory for frequently executed programs, such as text editors, the C compiler, the shells, and so on. Also, the text segment is often read-only, to prevent a program from accidentally modifying its instructions.
2. Initialized Data Segment:

Initialized data segment, usually called simply the Data Segment. A data segment is a portion of virtual address space of a program, which contains the global variables and static variables that are initialized by the programmer.

Note that, data segment is not read-only, since the values of the variables can be altered at run time.
This segment can be further classified into initialized read-only area and initialized read-write area.
For instance the global string defined by char s[] = “hello world” in C and a C statement like int debug=1 outside the main (i.e. global) would be stored in initialized read-write area. And a global C statement like const char* string = “hello world” makes the string literal “hello world” to be stored in initialized read-only area and the character pointer variable string in initialized read-write area.
Ex: static int i = 10 will be stored in data segment and global int i = 10 will also be stored in data segment
3. Uninitialized Data Segment:

Uninitialized data segment, often called the “bss” (Block Started by Symbol) segment, named after an ancient assembler operator that stood for “block started by symbol.” Data in this segment is initialized by the kernel to arithmetic 0 before the program starts executing

uninitialized data starts at the end of the data segment and contains all global variables and static variables that are initialized to zero or do not have explicit initialization in source code.
For instance a variable declared static int i; would be contained in the BSS segment.

For instance a global variable declared int j; would be contained in the BSS segment.

4. Stack:

The stack area traditionally adjoined the heap area and grew the opposite direction; when the stack pointer met the heap pointer, free memory was exhausted. (With modern large address spaces and virtual memory techniques they may be placed almost anywhere, but they still typically grow opposite directions.)

The stack area contains the program stack, a LIFO structure, typically located in the higher parts of memory. On the standard PC x86 computer architecture it grows toward address zero; on some other architectures it grows the opposite direction. A “stack pointer” register tracks the top of the stack; it is adjusted each time a value is “pushed” onto the stack. The set of values pushed for one function call is termed a “stack frame”; A stack frame consists at minimum of a return address.
Stack, where automatic variables are stored, along with information that is saved each time a function is called. Each time a function is called, the address of where to return to and certain information about the caller’s environment, such as some of the machine registers, are saved on the stack. The newly called function then allocates room on the stack for its automatic and temporary variables. This is how recursive functions in C can work. Each time a recursive function calls itself, a new stack frame is used, so one set of variables doesn’t interfere with the variables from another instance of the function.
5. Heap:

Heap is the segment where dynamic memory allocation usually takes place.

The heap area begins at the end of the BSS segment and grows to larger addresses from there.The Heap area is managed by malloc, realloc, and free, which may use the brk and sbrk system calls to adjust its size (note that the use of brk/sbrk and a single “heap area” is not required to fulfill the contract of malloc/realloc/free; they may also be implemented using mmap to reserve potentially non-contiguous regions of virtual memory into the process’ virtual address space). The Heap area is shared by all shared libraries and dynamically loaded modules in a process.
The size(1) command reports the sizes (in bytes) of the text, data, and bss segments. ( for more details please refer man page of size(1) )
1. Check the following simple C program
#include <stdio.h>int main(void){return 0;}
[narendra@CentOS]$ gcc memory-layout.c -o memory-layout
[narendra@CentOS]$ size memory-layout
text       data        bss        dec        hex    filename
960        248          8       1216        4c0    memory-layout
2. Let us add one global variable in program, now check the size of bss (highlighted in red color).
#include <stdio.h>int global; /* Uninitialized variable stored in bss*/int main(void){return 0;}
[narendra@CentOS]$ gcc memory-layout.c -o memory-layout
[narendra@CentOS]$ size memory-layout
text       data        bss        dec        hex    filename
960        248         12       1220        4c4    memory-layout
3. Let us add one static variable which is also stored in bss.
#include <stdio.h>int global; /* Uninitialized variable stored in bss*/int main(void){static int i; /* Uninitialized static variable stored in bss */return 0;}
[narendra@CentOS]$ gcc memory-layout.c -o memory-layout
[narendra@CentOS]$ size memory-layout
text       data        bss        dec        hex    filename
960        248         16       1224        4c8    memory-layout
4. Let us initialize the static variable which will then be stored in Data Segment (DS)
#include <stdio.h>int global; /* Uninitialized variable stored in bss*/int main(void){static int i = 100; /* Initialized static variable stored in DS*/return 0;}
[narendra@CentOS]$ gcc memory-layout.c -o memory-layout
[narendra@CentOS]$ size memory-layout
text       data        bss        dec        hex    filename
960         252         12       1224        4c8    memory-layout
5. Let us initialize the global variable which will then be stored in Data Segment (DS)
#include <stdio.h>int global = 10; /* initialized global variable stored in DS*/int main(void){static int i = 100; /* Initialized static variable stored in DS*/return 0;}
[narendra@CentOS]$ gcc memory-layout.c -o memory-layout
[narendra@CentOS]$ size memory-layout
text       data        bss        dec        hex    filename
960         256          8       1224        4c8    memory-layout
1.      Where are global local static extern variables stored?
  • Local Variables are stored in Stack. Register variables are stored in Register. Global & static variables are stored in data segment (BSS). The memory created dynamically are stored in Heap and the C program instructions get stored in code segment and the extern variables also stored in data segment
2.     What does BSS Segment store?
  • BSS segment stores the uninitialized global and static variables and initializes them to zero. I read that BSS segment doesn’t consume memory, then where those it store these variables? You probably read that the BSS segment doesn’t consume space in the executable file on disk. When the executable loaded, the BSS segment certainly does consume space in memory. Space is allocated and initialized to zero by the OS loader
3.         Global variable and Local variable-
  • Global variables once declared they can be used anywhere in the program i.e. even in many functions. If possible u can use the global variables in the different user defined header files as like in packages in java. On the other hand global variables values can be changed programmatically local variables are local to a functional and can’t be used beyond that function.
4.    Static variable and Global variable?
  • Static variables once declared they remain the same in the entire program and those values can’t be changed programmatically.
    global variables: check above description
Normally the C’s program building process involves four stages and utilizes different ‘tools’ such as a preprocessor, compiler, assembler, and linker.
  • At the end there should be a single executable file.  Below are the stages that happen in order regardless of the operating system/compiler and graphically illustrated in Figure w.1.
1.   Preprocessing is the first pass of any C compilation. It processes include-files, conditional compilation instructions and macros.
2.   Compilation is the second pass. It takes the output of the preprocessor, and the source code, and generates assembler source code.
3.   Assembly is the third stage of compilation. It takes the assembly source code and produces an assembly listing with offsets. The assembler output is stored in an object file.
4.   Linking is the final stage of compilation. It takes one or more object files or libraries as input and combines them to produce a single (usually executable) file. In doing so, it resolves references to external symbols, assigns final addresses to procedures/functions and variables, and revises code and data to reflect new addresses (a process called relocation).

  • Bear in mind that if you use the IDE type compilers, these processes quite transparent.
  • Now we are going to examine more details about the process that happen before and after the linking stage.  For any given input file, the file name suffix (file extension) determines what kind of compilation is done and the example for GCC is listed in Table w.1.
  • In UNIX/Linux, the executable or binary file doesn’t have extension whereas in Windows the executables for example may have .exe, .com and .dll
File extension
C source code which must be preprocessed.
C source code which should not be preprocessed.
C++ source code which should not be preprocessed.
C header file (not to be compiled or lin
C++ source code which must be preprocessed.  For file_name.cxx, the xx must both be literally character x and file_name.C, is capital c.
Assembler code.
Assembler code which must be preprocessed.
Object file by default, the object file name for a source file is made by replacing the extension .c, .i, .s etc with .o
Table w.1

The following Figure shows the steps involved in the process of building the C program starting from the compilation until the loading of the executable image into the memory for program running.   

Figure w.1:  Compile, link & execute stages for running program

  • After the source code has been assembled, it will produce an Object files (e.g. .o, .obj) and then linked, producing an executable files.
  • An object and executable come in several formats such as ELF (Executable and Linking Format) and COFF (Common Object-File Format).  For example, ELF is used on Linux systems, while COFF is used on Windows systems.
  • Other object file formats are listed in the following Table.
Object File Format
The a.out format is the original file format for Unix.  It consists of three sections: text, data, and bss, which are for program code, initialized data, and uninitialized data, respectively.  This format is so simple that it doesn’t have any reserved place for debugging information.  The only debugging format for a.out is stabs, which is encoded as a set of normal symbols with distinctive attributes.
The COFF (Common Object File Format) format was introduced with System V Release 3 (SVR3) Unix. COFF files may have multiple sections, each prefixed by a header. The number of sections is limited.  The COFF specification includes support for debugging but the debugging information was limited.  There is no file extension for this format.
A variant of COFF.  ECOFF is an Extended COFF originally introduced for Mips and Alpha workstations.
The IBM RS/6000 running AIX uses an object file format called XCOFF (eXtended COFF). The COFF sections, symbols, and line numbers are used, but debugging symbols are dbx-style stabs whose strings are located in the .debug section (rather than the string table).  The default name for an XCOFF executable file is a.out.
Windows 9x and NT use the PE (Portable Executable) format for their executables.  PE is basically COFF with additional headers.  The extension normally .exe.
The ELF (Executable and Linking Format) format came with System V Release 4 (SVR4) Unix.  ELF is similar to COFF in being organized into a number of sections, but it removes many of COFF’s limitations.  ELF used on most modern Unix systems, including GNU/Linux, Solaris and Irix. Also used on many embedded systems.
SOM (System Object Module) and ESOM (Extended SOM) is HP’s object file and debug format (not to be confused with IBM’s SOM, which is a cross-language Application Binary Interface – ABI).
Table w.2
  • When we examine the content of these object files there are areas called sections.  Sections can hold executable code, data, dynamic linking information, debugging data, symbol tables, relocation information, comments, string tables, and notes.
  • Some sections are loaded into the process image and some provide information needed in the building of a process image while still others are used only in linking object files.
  • There are several sections that are common to all executable formats (may be named differently, depending on the compiler/linker) as listed below:
This section contains the executable instruction codes and is shared among every process running the same binary. This section usually has READ and EXECUTE permissions only. This section is the one most affected by optimization.
BSS stands for ‘Block Started by Symbol’. It holds un-initialized global and static variables. Since the BSS only holds variables that don’t have any values yet, it doesn’t actually need to store the image of these variables. The size that BSS will require at runtime is recorded in the object file, but the BSS (unlike the data section) doesn’t take up any actual space in the object file.
Contains the initialized global and static variables and their values. It is usually the largest part of the executable. It usually has READ/WRITE permissions.
Also known as .rodata (read-only data) section. This contains constants and string literals.
Stores the information required for relocating the image while loading.
Symbol table
A symbol is basically a name and an address.  Symbol table holds information needed to locate and relocate a program’s symbolic definitions and references. A symbol table index is a subscript into this array. Index 0 both designates the first entry in the table and serves as the undefined symbol index.  The symbol table contains an array of symbol entries.
Relocation records
Relocation is the process of connecting symbolic references with symbolic definitions. For example, when a program calls a function, the associated call instruction must transfer control to the proper destination address at execution. Re-locatable files must have relocation entries’ which are necessary because they contain information that describes how to modify their section contents, thus allowing executable and shared object files to hold the right information for a process’s program image.  Simply said relocation records are information used by the linker to adjust section contents.
Table w.3:  Segments in executable file
  • The following is an example of the object file content dumping using readelf program.  Other utility can be used is objdump. 
/* testprog1.c */
#include <stdio.h>
static void display(int i, int *ptr);
int main(void)
      int x = 5;
      int *xptr = &x;
      printf(“In main() program:\n”);
      printf(“x value is %d and is stored at address %p.\n”, x, &x);
      printf(“xptr pointer points to address %p which holds a value of %d.\n”, xptr, *xptr);
      display(x, xptr);
      return 0;

void display(int y, int *yptr)
      char var[7] = “ABCDEF”; 
      printf(“In display() function:\n”);
      printf(“y value is %d and is stored at address %p.\n”, y, &y);
      printf(“yptr pointer points to address %p which holds a value of %d.\n”, yptr, *yptr);
[bodo@bakawali test]$ gcc -c testprog1.c
[bodo@bakawali test]$ readelf -a testprog1.o
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                                  ELF32
  Data:                                   2′s complement, little endian
  Version:                                1 (current)
  OS/ABI:            UNIX – System V
  ABI Version:              0
  Type:              REL (Relocatable file)
  Machine:           Intel 80386
  Version:           0×1
  Entry point address:      0×0
  Start of program headers: 0 (bytes into file)
  Start of section headers: 672 (bytes into file)
  Flags:                    0×0
  Size of this header:      52 (bytes)
  Size of program headers:  0 (bytes)
  Number of program headers:       0
  Size of section headers:         40 (bytes)
  Number of section headers:       11
  Section header string table index:      8

Section Headers:
  [Nr] Name          Type          Addr     Off        Size     ES Flg Lk Inf Al
  [ 0]               NULL          00000000 000000 000000 00      0   0  0
  [ 1] .text         PROGBITS      00000000 000034 0000de 00  AX   0   0  4
  [ 2] .rel.text     REL           00000000 00052c 000068 08      9   1  4
  [ 3] .data         PROGBIT       00000000 000114 000000 00         WA  0   0  4
  [ 4] .bss          NOBIT         00000000 000114 000000 00  WA  0   0  4
  [ 5] .rodata              PROGBITS      00000000 000114 00010a 00      A  0   0  4
  [ 6] .note.GNU-stack      PROGBITS      00000000 00021e 000000 00      0   0  1
  [ 7] .comment      PROGBITS      00000000 00021e 000031 00      0   0  1
  [ 8] .shstrtab     STRTAB 00000000 00024f 000051 00       0   0  1
  [ 9] .symtab              SYMTAB 00000000 000458 0000b0 10     10  9  4
  [10] .strtab              STRTAB 00000000 000508 000021 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

There are no program headers in this file.

Relocation section ‘.rel.text’ at offset 0x52c contains 13 entries:
 Offset       Info                 Type   Sym.Value  Sym. Name
0000002d  00000501 R_386_32 00000000   .rodata
00000032  00000a02 R_386_PC32      00000000   printf
00000044  00000501 R_386_32 00000000   .rodata
00000049  00000a02 R_386_PC32      00000000   printf
0000005c  00000501 R_386_32 00000000   .rodata
00000061  00000a02 R_386_PC32      00000000   printf
0000008c  00000501 R_386_32 00000000   .rodata
0000009c  00000501 R_386_32 00000000   .rodata
000000a1  00000a02 R_386_PC32      00000000   printf
000000b3  00000501 R_386_32 00000000   .rodata
000000b8  00000a02 R_386_PC32      00000000   printf
000000cb  00000501 R_386_32 00000000   .rodata
000000d0  00000a02 R_386_PC32      00000000   printf

There are no unwind sections in this file.

Symbol table ‘.symtab’ contains 11 entries:
   Num:    Value     Size Type    Bind        Vis             Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 00000000     0 FILE    LOCAL  DEFAULT  ABS testprog1.c
     2: 00000000     0 SECTION LOCAL  DEFAULT    1
     3: 00000000     0 SECTION LOCAL  DEFAULT    3
     4: 00000000     0 SECTION LOCAL  DEFAULT    4
     5: 00000000     0 SECTION LOCAL  DEFAULT    5
     6: 00000080     94 FUNC   LOCAL  DEFAULT    1 display
     7: 00000000     0 SECTION LOCAL  DEFAULT    6
     8: 00000000     0 SECTION LOCAL  DEFAULT    7
     9: 00000000     128 FUNC  GLOBAL DEFAULT    1 main
    10: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND printf                NEXT->>

1 comment: