How is ELF entry point address handled on systems without virtual memory?

0
votes

On systems with MMU and support for virtual memory there can be multiple ELFs with the same entry point loaded at the same time as their entry points are just virtual addresses and are translated to physical memory address at runtime. For example, on my amd64 machine .text section is always mapped at address 0x00400000 and _start is always close to that address. But how does it work on systems without MMU? Many of them probably don't support multitasking at all. Is it developers' responsibility to pick ELF entry points by hand so that they don't overlap?

1
memoryembeddedelfmmu
It depends on what you're trying to accomplish. Are you using an underlying OS, such as Linux compiled without MMU support, running ELFs on top? – Nikopol
I don't run anything and don't want to build a new operating system, I'm just asking. For example uclinux can be installed on MMU-less machines, how do they handle this issue? My question is more generic though, uclinux is just an example. – user1042840
Sorry, I'm not familiar with uclinux. If you want to support executing multiple ELFs on MMU-less machines, you will usually have to compile them as position independent executables. Otherwise, you have no way to solve the mapping conflicts between multiple ELFs you're trying to run. – Nikopol
I don't know about ELF but in case of the Portable Executable (PE) format (used by Windows) it can be completely relocated by the OS to whichever address the OS chooses. So it is not developer's responsibility. It is the OS responsibility – xmojmr
@xmojmr - it's still the developer's responsibility to use a toolchain/linker which produces an output file compatible with such usage. – Chris Stratton

1 Answers

1
votes

Short story, it does not handled anyhow.

And now there is a long story.

ELF is not executable as is, it's sort of container with executable data. In systems with OS and MMU, OS creates a process and respective MMU page tables for that process. After that read ELF and copy executable code and data sections (BSS) into this newly allocated process memory according to data in ELF file. Once that done, program counter is set to entry point address. You program runs. Hooray.

Important point to highlight is that every process has it's own virtual memory which is mapped into unique physical memory. So virtual addresses could overlap or be the same for different processes, while physical addresses are always different at any given moment.

Now there is a system without MMU. So there is no virtual memory, every process should be placed in unique physical memory region and linked to that precise memory region.

In real life if there is some small system w/o MMU ELF files simply not used. Option 1, all apps linked together into one big binary. Option 2, apps linked separately with unique addresses, executable information is extracted with some 'objcopy' util, and that binaries copied into system for execution. 'OS' should have a list of entry point to start these 'processes'.