Question about memory management in L4 Fiasco O.C + L4re

[Adam Lackorzynski]

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
-- 
Adam                 adam at os.inf.tu-dresden.de
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/