Hi,
On Wed Oct 07, 2015 at 15:42:36 +0200, Mahdi Aichouch wrote:
In order to be sure that I correctly understand how Dataspace and Memory Allocator work, I tried an example where Dataspace are created using the "L4Re::Mem_alloc::Continuous and L4Re::Mem_alloc::Pinned" flags. This will ensure that the allocated physical memory is contiguous and can not be moved, right?
Exactly.
My second question concerns the way how an L4 task is loaded into memory. Do you think that it is possible to make all segments of an L4 user program to be adjacent in physical memory. As an example, given one L4 user program we would like to have the following configuration:
Physical memory
0x000000 0MB
0x100000 1MB text 0x200000 2MB data 0x300000 3MB stack 0x400000 4MB heap 0x500000 5MB
(the memory addresses are given here for illustration purpose)
From my tracing of Moe, L4re and libloader using Moe::Dataspace::phys( )
function, I saw that some areas were adjacent and other were not. Could you please give an explanation of how Moe and l4re load a user program from a disk into memory.
The loaders just load the binary, i.e. the layout of the binary needs to be according to your requirements. The loaders will not and cannot change how the binary has been built. The layout of binaries is generated according to the linker script used when linking the program. That allows you to generate a layout according to your requirements. The linker script used in L4Re are in pkg/ldscripts, bootstrap uses a specific linker script. What you are looking for are the program headers in the ELF binary, look at them using objdump or readelf. This way you can influence the layout of a binary and possibly pull sections together. However, this is not enough because a stack will also be dynamically allocated by the loader and its location is not defined by the binary. I think here you need to ensure within the loader that they are close to the loaded binary. Remember it's good to have an address space hole below the stack to detect stack overflows. Plus, the memory allocator must supply memory that physically adjacent to the heap. I guess that needs some extension in moe's allocators at least and according usage in libloader where the memory for programs is allocated.
Adam