Структура сегментов в адресном пространстве процесса

#память #процесс

|----------------------------Kernel Space------------------------------|  0xFFFFFF
                                                                 
|                                                                      |
|                                                                      |
|                                                                      |
|↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓Stack↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓|
|                                                                      |
|                                                                      |
|                                                                      |
|↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓Memory mapping segment↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓|
|                                                                      |
|                                                                      |
|                                                                      |
|↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑Heap↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑|
|                                                                      |
|                                                                      |
|-----------------------------BSS  segment-----------------------------|
|-----------------------------Data segment-----------------------------|
|-----------------------------Text segment-----------------------------|
|                                                                      |
|---------------------------------OS-----------------------------------|
|________________________________BIOS__________________________________| 0x000000 


Вопросы:

1) Как устроен Memory mapping segment?

2) Есть ли сегмент для констант?

3) В С++ есть и Heap и Free Store, или Heap интерпретируется как Free Store (если
да, то как размещен?) ?

4) Есть сегменты(с показанных выше) которые могут отсутствовать?

5) Есть замечания к указанной структуре памяти?
    

Ответы

Ответ 1

Константы обычно размещаются в текстовом сегменте, т.к. он защищен от записи. 

В остальном картинка условно соответствует большинству реализаций с виртуальной памятью.
Также следует иметь в виду, что между показанными сегментами возможны "дыры" (в смысле
пространства виртуальных адресов). 

Распределение памяти для конкретных Linux программ на практике можно посмотреть в
файле /proc/{PID}/maps

В качестве примера, вот такая программка и результат ее выполнения:

avp@avp-ubu1:hashcode$ cat t-maps.c
#include 
#include 
#include 

static int data = 22;

int
main (int ac, char *av[])
{
  const char *p = "xaxa-xaxaxaxax";

  printf("main: %p  p: %p  &p: %p  &data: %p\n",
     main, p, &p, &data);
  char str[100];
  sprintf(str, "cat /proc/%d/maps", (int)getpid());
  system(str);
}
avp@avp-ubu1:hashcode$ g++ t-maps.c && ./a.out
main: 0x56352bf8278a  p: 0x56352bf828b8  &p: 0x7ffff853a718  &data: 0x56352c183010
56352bf82000-56352bf83000 r-xp 00000000 08:01 1179691                    /home/avp/hashcode/a.out
56352c182000-56352c183000 r--p 00000000 08:01 1179691                    /home/avp/hashcode/a.out
56352c183000-56352c184000 rw-p 00001000 08:01 1179691                    /home/avp/hashcode/a.out
56352ce80000-56352cea1000 rw-p 00000000 00:00 0                          [heap]
7fd21e33c000-7fd21e356000 r-xp 00000000 08:01 2159140                    /lib/x86_64-linux-gnu/libpthread-2.27.so
7fd21e356000-7fd21e555000 ---p 0001a000 08:01 2159140                    /lib/x86_64-linux-gnu/libpthread-2.27.so
7fd21e555000-7fd21e556000 r--p 00019000 08:01 2159140                    /lib/x86_64-linux-gnu/libpthread-2.27.so
7fd21e556000-7fd21e557000 rw-p 0001a000 08:01 2159140                    /lib/x86_64-linux-gnu/libpthread-2.27.so
7fd21e557000-7fd21e55b000 rw-p 00000000 00:00 0 
7fd21e55b000-7fd21e55e000 r-xp 00000000 08:01 2159128                    /lib/x86_64-linux-gnu/libdl-2.27.so
7fd21e55e000-7fd21e75d000 ---p 00003000 08:01 2159128                    /lib/x86_64-linux-gnu/libdl-2.27.so
7fd21e75d000-7fd21e75e000 r--p 00002000 08:01 2159128                    /lib/x86_64-linux-gnu/libdl-2.27.so
7fd21e75e000-7fd21e75f000 rw-p 00003000 08:01 2159128                    /lib/x86_64-linux-gnu/libdl-2.27.so
7fd21e75f000-7fd21e946000 r-xp 00000000 08:01 2159125                    /lib/x86_64-linux-gnu/libc-2.27.so
7fd21e946000-7fd21eb46000 ---p 001e7000 08:01 2159125                    /lib/x86_64-linux-gnu/libc-2.27.so
7fd21eb46000-7fd21eb4a000 r--p 001e7000 08:01 2159125                    /lib/x86_64-linux-gnu/libc-2.27.so
7fd21eb4a000-7fd21eb4c000 rw-p 001eb000 08:01 2159125                    /lib/x86_64-linux-gnu/libc-2.27.so
7fd21eb4c000-7fd21eb50000 rw-p 00000000 00:00 0 
7fd21eb50000-7fd21eb56000 r-xp 00000000 08:01 3670234                    /usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0
7fd21eb56000-7fd21ed55000 ---p 00006000 08:01 3670234                    /usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0
7fd21ed55000-7fd21ed56000 r--p 00005000 08:01 3670234                    /usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0
7fd21ed56000-7fd21ed57000 rw-p 00006000 08:01 3670234                    /usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0
7fd21ed57000-7fd21ed7e000 r-xp 00000000 08:01 2159121                    /lib/x86_64-linux-gnu/ld-2.27.so
7fd21ef5a000-7fd21ef5e000 rw-p 00000000 00:00 0 
7fd21ef7e000-7fd21ef7f000 r--p 00027000 08:01 2159121                    /lib/x86_64-linux-gnu/ld-2.27.so
7fd21ef7f000-7fd21ef80000 rw-p 00028000 08:01 2159121                    /lib/x86_64-linux-gnu/ld-2.27.so
7fd21ef80000-7fd21ef81000 rw-p 00000000 00:00 0 
7ffff851c000-7ffff853d000 rw-p 00000000 00:00 0                          [stack]
7ffff8563000-7ffff8566000 r--p 00000000 00:00 0                          [vvar]
7ffff8566000-7ffff8568000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
avp@avp-ubu1:hashcode$