---- Andy Wingo <[email protected]> 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
