理解虚拟内存，重温elf内存映射
revisiting elf memory mapping with understanding of virtual memory
参考以下问题
1 How are the different segments like heap, stack, text related to the physical memory?
2 memory allocation in data/bss/heap and stack
3 how does a program runs in memory and the way memory is handled by Operating system
4 How convert address in elf to physical address
特别是问题1中要求明确的地方还需要专家点评
同时 answers/comments 在相反的方向使这更混乱。我们所知道的是，elf 被加载到虚拟地址 space 中，当需要实际物理页面时，MMU 会为进程提供该页面。我对此深表怀疑。如果仅在虚拟地址中进行映射，那么如何开始执行？一种可能性是来自 elf 二进制文件的段被加载到虚拟地址 space 并且还会创建一个空的页表，该页表会在每次内存访问时出现页面错误时填充。并且在这个群体中没有存储在 disk.I 上的 ELF 二进制文件的作用可以删除我存储在磁盘上的 elf 而不会影响执行吗？
如果上述理解是正确的，那么混淆就在于我们对虚拟内存缺乏了解。由于 VM 被认为是欺骗，但似乎不止于此。假设 int x=12 当此行加载到 virtual space 时，这意味着 VM 中存在 x (12) 值的记录。当某些指令 mov x,register 第一次执行时，在 RAM 中创建一个页面只是为了给出实际的 space 来使这条指令 运行?
在注意到我和其他有类似问题的人的声誉分数之后，即使这是基本问题，这个概念至少给我造成了很多困惑。
if above understanding is right confusion lies in lack of knowledge on our side about virtual memory.
The understanding you state is not right, but your confusion certainly does seem to be largely about virtual memory. The point of a virtual memory system is to allow each process to access the whole address space (more or less) as if it were the only process 运行, and without regard to how much physical RAM is available. "Virtual" does not mean "fake" or any such thing -- with one or two caveats, if a program has virtual memory assigned to it, then it has bona fide贮存。 The "virtual" part has to do with the real location at any given time of the storage associated with any particular virtual address.
You also seem to be confusing yourself by associating ELF too closely with virtual memory. Certainly the OS will normally load an ELF executable into virtual memory (backed by some combination of physical RAM and disk that may vary over time), but it would do the same with a program in any other executable format it supports, and there are others.
I have severe doubts about this. if mappings are only made in virtual address then how execution is started?
The operating system kernel is the exception -- it runs in real memory. Managing virtual memory for all 运行 processes is one of its jobs, and the page table for each process belongs to it, not to the process. The kernel handles setting up and starting processes, including their page tables, and at all times it knows the actual location of all storage assigned to each one, and to what virtual addresses that storage is mapped.
And in this population there is no role of ELF binary stored on disk. I can delete my elf stored on disk with out [a]ffecting execution?
The ELF binary stored on disk contains executable code and data for the program that will be loaded into the process's (virtual) memory when the program is launched. This is the job of the ELF dynamic linker (ld.linux.so.2, for example). Certainly the ELF file is needed to launch the program. After the process has started, then sure, the on-disk ELF binary can be unlinked (via the rm command, for example) without affecting the execution of the program, since it has been loaded into memory (on Unix-like systems; Windows is different, but does not support ELF). That binary will then be unavailable to launch any new instance of the program.
Note, however, that unlinking is not necessarily the same thing as deleting. As long as any process has the unlinked file open, it will remain allocated on the file system. This may well be the case for a 运行 ELF program, as one good loading strategy is to map parts of the binary file into memory (the .text and .rodata sections,例如）。 This will hold the file open as long any process with such mappings is alive, even if the binary is unlinked from the file system.
参考以下问题
1 How are the different segments like heap, stack, text related to the physical memory?
2 memory allocation in data/bss/heap and stack
3 how does a program runs in memory and the way memory is handled by Operating system
4 How convert address in elf to physical address
特别是问题1中要求明确的地方还需要专家点评
同时 answers/comments 在相反的方向使这更混乱。我们所知道的是，elf 被加载到虚拟地址 space 中，当需要实际物理页面时，MMU 会为进程提供该页面。我对此深表怀疑。如果仅在虚拟地址中进行映射，那么如何开始执行？一种可能性是来自 elf 二进制文件的段被加载到虚拟地址 space 并且还会创建一个空的页表，该页表会在每次内存访问时出现页面错误时填充。并且在这个群体中没有存储在 disk.I 上的 ELF 二进制文件的作用可以删除我存储在磁盘上的 elf 而不会影响执行吗？
如果上述理解是正确的，那么混淆就在于我们对虚拟内存缺乏了解。由于 VM 被认为是欺骗，但似乎不止于此。假设 int x=12 当此行加载到 virtual space 时，这意味着 VM 中存在 x (12) 值的记录。当某些指令 mov x,register 第一次执行时，在 RAM 中创建一个页面只是为了给出实际的 space 来使这条指令 运行?
在注意到我和其他有类似问题的人的声誉分数之后，即使这是基本问题，这个概念至少给我造成了很多困惑。
if above understanding is right confusion lies in lack of knowledge on our side about virtual memory.
The understanding you state is not right, but your confusion certainly does seem to be largely about virtual memory. The point of a virtual memory system is to allow each process to access the whole address space (more or less) as if it were the only process 运行, and without regard to how much physical RAM is available. "Virtual" does not mean "fake" or any such thing -- with one or two caveats, if a program has virtual memory assigned to it, then it has bona fide贮存。 The "virtual" part has to do with the real location at any given time of the storage associated with any particular virtual address.
You also seem to be confusing yourself by associating ELF too closely with virtual memory. Certainly the OS will normally load an ELF executable into virtual memory (backed by some combination of physical RAM and disk that may vary over time), but it would do the same with a program in any other executable format it supports, and there are others.
I have severe doubts about this. if mappings are only made in virtual address then how execution is started?
The operating system kernel is the exception -- it runs in real memory. Managing virtual memory for all 运行 processes is one of its jobs, and the page table for each process belongs to it, not to the process. The kernel handles setting up and starting processes, including their page tables, and at all times it knows the actual location of all storage assigned to each one, and to what virtual addresses that storage is mapped.
And in this population there is no role of ELF binary stored on disk. I can delete my elf stored on disk with out [a]ffecting execution?
The ELF binary stored on disk contains executable code and data for the program that will be loaded into the process's (virtual) memory when the program is launched. This is the job of the ELF dynamic linker (ld.linux.so.2, for example). Certainly the ELF file is needed to launch the program. After the process has started, then sure, the on-disk ELF binary can be unlinked (via the rm command, for example) without affecting the execution of the program, since it has been loaded into memory (on Unix-like systems; Windows is different, but does not support ELF). That binary will then be unavailable to launch any new instance of the program.
Note, however, that unlinking is not necessarily the same thing as deleting. As long as any process has the unlinked file open, it will remain allocated on the file system. This may well be the case for a 运行 ELF program, as one good loading strategy is to map parts of the binary file into memory (the .text and .rodata sections,例如）。 This will hold the file open as long any process with such mappings is alive, even if the binary is unlinked from the file system.