1

with reference to following questions

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

especially in question 1 what is asked to clear still needs experts comments.

at the same time different answers/comments in opposite directions making this more confusing. what we know is that elf is loaded in virtual address space and when needed the actual physical page, process is provided with that page by MMU. I have severe doubts about this. if mappings are only made in virtual address then how execution is started? one possibility is that segments from elf binary are loaded into virtual address space and an empty pagetable is also created which is populated on page faults on each memory access. And in this population there is no role of ELF binary stored on disk.I can delete my elf stored on disk with out effecting execution?
if above understanding is right confusion lies in lack of knowledge on our side about virtual memory. As VM is considered deception but it seems it is more than that. lets say int x=12 when this line is loaded in virtual space it means there is record keeping for value of x (12) in VM. when some instruction mov x,register is executed for the first time, a page is created in RAM only to give actual space to make this instruction run?

After noticing the reputation scores of mine and others with similar question even if this is basic question, this concept is creating a lot of confusions for me at least.

Community
  • 1
  • 1
incompetent
  • 1,715
  • 18
  • 29

1 Answers1

1

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 running, 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 storage. 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 running 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 running ELF program, as one good loading strategy is to map parts of the binary file into memory (the .text and .rodata sections, for example). 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.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157
  • wow very nice. if i am writing ELF loader for my own OS, I will read segments from ELF and map them in Virtual memory? there is nothing in ELF binary to be loaded into physical memory by ELF loader. Page table manager will get pages on need and fill that pages with instructions/data _already loaded in virtual memory_ for mapped segments? – incompetent Jun 27 '15 at 20:09
  • No, incorrect. An ELF loader will normally need to be prepared to allocate and initialize at least some memory, such as for `.bss` sections. It cannot just map `.bss` sections into memory because they contain only descriptions of the data within, not any storage for the data themselves. There may be other sections that present similar requirements. – John Bollinger Jun 28 '15 at 16:19
  • On the other hand, you still seem to have an inappropriate fixation on distinguishing physical memory from virtual memory. On a typical virtual-memory OS, *nothing running in user space can tell the difference*. That probably includes your ELF loader itself. As far as a user-space program can tell, memory is just memory. Even explicitly mapping a file into memory via `mmap()` does not present an exception -- a program cannot tell *how* that mapping is provided, and code using the memory cannot tell that it is mapped.. – John Bollinger Jun 28 '15 at 16:28