[0x03]. Notes on Assembly - Memory from a process' point of view

In-depth memory layout is specific to both the CPU architecture and the OS itself. I'm going to describe how a process sees its own memory share during execution.

Memory Layout from a process perspective

When a program is executed it is read into memory* where it resides until termination. The code allocates a number of special purpose memory blocks for different data types. A very common scheme, but not the only one, is depicted in the following table.

*that's why a statement that the size of your binary does not influence the memory use is not true. Programs static code is read into the lower part of memory.

Stack a very dynamic kind of memory located at it's top (high addresses) and growing downwards

Memory not allocated yet Memory that will soon become allocated by the stack, that grows down. Stack will grow until it hits the administrative limit (predefined). Administrative limit for the stack

Shared Libraries

Administrative limit for the heap Memory not allocated yet Memory that will soon become allocated by the heap growing up from underneath.

Heap It is said that this is the most dynamic part of memory. It is dynamically allocated and freed in big chunks. The allocation process is rather complex (stub/buddy system) and is more time consuming than putting things on stack.

BSS Memory containing global variables of known (predeclared) size.

Constant data All constants used in a program.

Static program code

Reserved / other stuff

In order to prove that things work this way (on many systems anyway) I wrote a C program, mem_sequence.c, that allocates 5 types of data, finds their location the (virtual) memory address, sorts them in descending order and then displays presenting a similar output to the table above. mem_sequence.c is tested on Linux, FreeBSD, MacOS X, WinXP and DOS. All UNIX-like systems preserve a similar model with slight differences in address thresholds, the output from Microsoft systems is different and hence interesting.

This is how you use mem_sequence:

$ gcc mem_sequence.c -o mem_sequence
$ ./mem_sequence
1.(0xbf828124) stack
2.(0x0804a008) heap
3.(0x080497d4) bss
4.(0x08048688) const's
5.(0x08048557) code
^Z
[1]+  Stopped                 ./mem_sequence
$ cat /proc/`pidof mem_sequence`/maps
08048000-08049000 r-xp 00000000 fd:01 313781     mem_sequence
08049000-0804a000 rw-p 00000000 fd:01 313781     mem_sequence
0804a000-0806b000 rw-p 0804a000 00:00 0          [heap]
b7dda000-b7ddb000 rw-p b7dda000 00:00 0
b7ddb000-b7efe000 r-xp 00000000 fd:01 4872985    /lib/libc-2.5.so
b7efe000-b7eff000 r--p 00123000 fd:01 4872985    /lib/libc-2.5.so
b7eff000-b7f01000 rw-p 00124000 fd:01 4872985    /lib/libc-2.5.so
b7f01000-b7f04000 rw-p b7f01000 00:00 0
b7f18000-b7f1b000 rw-p b7f18000 00:00 0
b7f1b000-b7f35000 r-xp 00000000 fd:01 4872978    /lib/ld-2.5.so
b7f35000-b7f36000 r--p 00019000 fd:01 4872978    /lib/ld-2.5.so
b7f36000-b7f37000 rw-p 0001a000 fd:01 4872978    /lib/ld-2.5.so
bf816000-bf82b000 rw-p bffeb000 00:00 0          [stack]
ffffe000-fffff000 r-xp 00000000 00:00 0          [vdso]
$

Let's analyze it:

• The code (5) and constants (4) fall into the readable and executable (non-writable!) portion of code.
• BSS (3) is enclosed in the read-write but not executable partition.
• Heap sits on top of them and is denoted by "[Heap]".
• ...long long nothing...
• Stack at the very top, described as "[Stack]". Yahtzee!
  

It works, great news, but it works differently on different x86 based Operating Systems. Check it out yourself and please let me know if you make an interesting discovery on some other exotic system.

top	Linux	FreeBSD	MacOSX x86 / PPC	WinXP 32	DOS	AmigaOS 4.1	Vista Home 32bit
1	stack	stack	stack	heap	heap	code	bss
2	heap	heap	heap	bss	stack	heap	const's
3	bss	bss	bss	const	bss	bss	code
4	const	const	const	code	const	const's	heap
5	code	code	code	stack	code	stack	stack

Thanks to Harald Monihart for providing MacOSX PPC data.
Thanks to Anonymous for AmigaOS 4.1 data.