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

Questions:

1) How is the Memory mapping segment ?

2) Is there a segment for constants?

3) In C ++, there are both Heap and Free Store , or is Heap interpreted as a Free Store (if so, how is it located?)?

4) Are there segments (as shown above) that may be missing?

5) Any comments on this memory structure?

  • memory mapping is arranged depending on the processor used. In general, you can see typing in Google, for example, "page transformation x86". Just keep in mind that even with this one type of processors, depending on the operation modes, 6 slightly different mechanisms can be applied. And it is worth remembering that shown in your picture is very conditional. Segments can be located in memory in completely different ways, depending on the OS used. And the addresses on the right on the picture do not make sense at all. The constant segment is not required, since the constants are protected in the commands themselves. - Mike
  • Only one remark - the structure drawn has little to do with reality. And in C ++ there is neither heap, nor free store (more precisely, they don’t set the program structure in memory). - VTT
  • although by memory mapping it is quite possible in this case, not page tables, but files reflected in memory. You should clarify what you mean by that - Mike
  • 2) the constants, as a rule, are located in the data segment 5) the segments are not necessarily arranged in that order. Heaps, stacks, date, text can be in any order. As far as I know, they are distributed by os itself - Alexander
  • @Alexander In data all global variables. Both variable, with given initial values, and large constant structures. Constants occupying less than 8 bytes (size depending on the architecture, of course) are not stored there, unless pointers to them are required - Mike

1 answer 1

Constants are usually placed in the text segment, because it is write protected.

In the rest of the picture conditionally corresponds to the majority of implementations with virtual memory. It should also be borne in mind that "holes" are possible between the segments shown (in the sense of the virtual address space).

Memory allocation for specific Linux programs in practice can be found in the file / proc / {PID} / maps

As an example, here is the program and the result of its implementation:

 avp@avp-ubu1:hashcode$ cat t-maps.c #include <stdio.h> #include <stdlib.h> #include <unistd.h> static int data = 22; int main (int ac, char *av[]) { const char *p = "xaxa-xaxaxaxax"; printf("main: %pp: %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$