Re: [PATCH] Use mmap for symbol tables

[Eirik Fuller <eirik@hackrat.com>]

> Been there, done that, with IRIX/dbx and  'just virtual address
> space' was a disaster for a few big apps

I don't know how dbx handles symbol tables, but in my experience the
size of a symbol table needs to be within a particular power of two to
exhaust virtual address space in a situation where gdb won't exhaust it
anyway with malloc.  A debugger which only keeps a small subset of a
symbol table resident in memory (whether it uses malloc or mmap) can
obviously handle much larger symbol tables, but in my experience that
doesn't describe gdb.

If the mmap patch is runtime optional and disabled by default, it won't
make corner cases with large symbol tables any worse.  I believe the
right long term answer is a better symbol table format (with indexing
stored on disk), even on 64 bit hosts.

> The size of the text and the data can be very large indeed.
> And those, as mmap,  are not going to be used normally.
> So are wasted virtual address space in the debugger.

This suggests a simple way to complicate my mmap patch.  If it can be
determined beforehand what interval of the symbol table gdb is going to
read in its entirety, that interval can be recorded in the BFD struct,
and the first mmap call can map just that interval.  That will
complicate the offset calculations somewhat, but the basic approach will
be the same.  This will only waste virtual address space if the sections
gdb would otherwise read don't form a contiguous region of the file.