Re: [PATCH] Use mmap for symbol tables

[Eirik Fuller <eirik@hackrat.com>]

> One important note: you bypassed symfile_relocate_debug_section.

I'll look at it.  It hasn't yet been an issue in anything I've used my
gdb mmap patches with, but offhand I'd expect it should be easy to find
something that does trip over that.  I can watch attempts to write back
to the readonly mmap region from gdb, and maybe cobble together some
malloc glue which provides the illusion of copy on write.  Or maybe just
convince myself that MAP_PRIVATE is the right answer (but it might be
better to keep PROT_READ, just to really keep track of what gdb needs to
modify and what it doesn't need to modify).

> you'll get better hot-cache performance because two consecutive
> sessions can do DWARF processing on pages already read in

That sounds similar to my earlier observation about the memory footprint
of concurrent gdb sessions on the same symbol table, but if I understand
correctly you're saying that even consecutive (non-overlapping) gdb
sessions can benefit if pages stay in the page cache.  I think that was
visible to some extent in the comparative timing between read and mmap
for the case where the symbol table was already in the page cache (mmap
was roughly two seconds faster, 43 versus 45).