Re: thinking out loud: wip-rtl, ELF, pages, and mmap

[<dsmich@roadrunner.com>]

---- Andy Wingo <wingo@pobox.com> wrote: 

...

> Then I realized: why am I doing all of this if the kernel has a virtual
> memory system already that does all this for me?
> 
> So I have a new plan, I think.  I'll change the linker to always emit
> sections and segments that correspond exactly in their on-disk layout
> and in their in-memory layout.  (In ELF terms: segments are contiguous,
> with p_memsz == p_filesz.)  I'll put commonly needed things at the
> beginning, and debugging info and the section table at the end.  Then
> I'll just map the whole thing with PROT_READ, and set PROT_WRITE on
> those page-aligned segments that need it.  (Obviously in the future,
> PROT_EXEC as well.)
> 
> Then I'll just record a list of ELF objects that have been loaded.
> Simple bisection will map IP -> ELF, and from there we have the section
> table in memory (lazily paged in by the virtual memory system) and can
> find the symtab and other debug info.
> 
> So that's the plan.  It's a significant change, and I wondered if folks
> had some experience or reactions.
> 
> Note that we have a read()-based fallback if mmap is not available.
> This strategy also makes the read-based fallback easier.
> 
> Thoughts?

Sounds like a great idea!  I think it's good to use the facilities
that already exist instead of reinventing the wheel.

A thought was that this would artificially bloat the size of the process
when the extra info isn't being used.  But so what?  The *real* memory
won't be consumed.  And it's not like we are running out of addressable
memory space anyway.  It will be a bit ickier for systems without
virtual memory.

What about non-ELF systems?  You are using your own ELF reader and mmap, not
relying on the system to load the files right?  So that's not an issue?

-Dale