Re: [PATCH] Use mmap for symbol tables

[David Anderson <davea@quasar.engr.sgi.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.

The problem was not symbol tables (which IRIX dbx does not
do as well as gdb!) but the 'gratuitous' mapping
in of the text and data space of the executable and
shared libraries -- just to get to symbol data.
We got away with it for a long time, but people do press
the boundaries and eventually we had to redo it.
What with memory so cheap and cpus so fast these days
more and more apps press these boundaries.


>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.

An intriguing observation. 

For most Elf files your 'simple way' will work, I think.
How often it won't is unclear...

Don't let my opinions discourage you, you are doing good work
whether or not it gets into gdb at this point.


David Anderson