OSDev.org

Hi,

I've a simple ELF loader in my os. It's not bad, but some parts of my ELF loader is not optimal.

I map ELF sections to corresponding virtual addresses with map_memory(elf_task->page_directory, section->virtual_address, section->size_in_memory, FLAGS_RW | FLAGS_USER) but I can't copy them because these sections are mapped in elf_task's page directory, not in current page directory.

I fixed that by mapping these sections in current page directory instead, copying them to corresponding locations, then unmapping them in current page directory and lastly re-mapping them in elf_task->page_directory.

It looks like that:

map_memory(current_page_directory, section->virtual_address, section->size_in_memory, FLAGS_RW | FLAGS_USER);
memcpy(section->virtual_address, sect_data, section->size_in_memory);
unmap_memory(current_page_directory, section->virtual_address, section->size_in_memory, FLAGS_RW | FLAGS_USER);
map_memory(elf_task->page_directory, section->virtual_address, section->size_in_memory, FLAGS_RW | FLAGS_USER);

but double mapping for each section isn't optimal.

I thought switching to elf_task->page_directory, copying sections and switching to page directory that I switched from like that:

page_directory_t* old_page_directory = current_page_directory;
switch_page_directory(elf_task->page_directory);
memcpy(section->virtual_address, sect_data, section->size_in_memory);
switch_page_directory(old_page_directory);

but this causes a full TLB flush for each ELF file. Is there a more optimal way to do it?

Thanks in advance.

If you set aside the second memory map for a moment, what you are performing is inter-process memory copy. I am not aware of any way to achieve that without mapping and unmapping the other process's pages, unless you are using the linux approach and you map the whole physical memory in the kernel. In such case, you could have a routine to copy directly from the physical memory by manually traversing the other process's page tables, without having to map those pages in your address space. But it is not that critical an improvement considering the cost of the copy itself and the frequency of loading elfs.

You could also implement copy on write. The section data is just a memory mapped file of sorts, which for ET_EXEC is not supposed to change much. Thus you can implement a facility in the kernel that maps the elf pages (or any other pages) as read-only in the target process, but with some indication (i.e. flag/structure) stored somewhere to remember that they are in fact writable after duplication. Thus on a page fault, the kernel will copy the page and resume the write instruction that faulted. This approach delegates the copying responsibility to the kernel, and is not that much faster, but is performed on demand. As I said, in most cases the copy will never happen. This improves the memory usage, because multiple processes that use the same executable now alias the same physical memory, not copies of it.

P.S. The copy on write I described above assumes that you have memory mapped files already, to be used as a starting point. That is - you must be able to tell the kernel - map this block range of this file in this virtual address range of that process. The copy on write is only an extension that says - and treat it as an on-demand duplicate.

Why do you need to copy elf sections around? Just map them into the process and use.

Set proper sections alignment to match your page size.