Mapping memory into process address space

Björn Döbel doebel at
Wed Aug 13 08:50:48 CEST 2014

Hash: SHA1

On 13.08.2014 04:26, Noah Zentzis wrote:
> I'm trying to launch a new process (without libloader) and I'm
> having trouble mapping memory to it. I've found the prog_attach_ds
> and prog_reserve_utcb_area methods in libloader and ned, but I'm
> not sure where they're getting the memory to assign

The dataspace that prog_attach_ds() is called with is allocated by the
ELF loader in libloader/include/elf.

reserve_utcb_area() is supposed to not attach a real dataspace but
reserve a virtual memory area that will not be used by the new
application's RM to attach any other memory, because this is where the
UTCBs will later be mapped to by the kernel iirc.

> or the region map for the task. Can I just do something like:
> L4Re::Util::Cap<L4Re::Dataspace> stack; 
> L4Re::Env::mem_alloc()->alloc(0x10000, stack);

Nothing wrong with that (except missing error checking :)).

> or are there special steps I need to take when I want to give
> another process access to the same memory?

Now that you allocated a stack above, you need to map this stack to
the newly created application. At this point your best way to do so is
to use the L4::Task::map() operation on the capability of your newly
created task. This allows you to map memory and capabilities to the
new program even though it is not running yet.

May I ask what you are trying to achieve? Based on my experience, if
you are trying to load an ELF binary and maybe even want your program
to use L4Re's region manager for memory management, I'd recommend
going the libloader route, even if the interface may seem inscrutable
at first. If you are loading something else, then just ignore my
comment. ;)

Version: GnuPG v1
Comment: Using GnuPG with Icedove -


More information about the l4-hackers mailing list