Re: [PATCH] Use mmap for symbol tables

[David Anderson <davea at quasar dot engr dot sgi dot com>]

Jim Blandy
> I understand that it would make your BFD code more complicated, but it
> seems to me you want to map individual sections, not entire files.
> Again, this will still share memory with the block cache, so aside
> from the complexity I don't see the downside.

Eirik Fuller
>I don't see the upside of making the code more complicated.  The
>downside of the extra complication is that it makes the patch less
>likely to the point of never actually existing.  :-)
>
>Could you be more specific about why multiple mmap regions per file are
>preferable?  (It might help to keep in mind that I'm using PROT_READ and
>MAP_SHARED).  The only downside I can see is the (relatively small)
>fraction of each symbol table which is not accessed via mmap, but that
>doesn't use memory, just virtual address space (if it does use memory,
>that contradicts the "not accessed" part).

Hope the following is not out of line.

The phrase 'just virtual address space' should not, IMO, be
uttered so cavalierly.  Mapping in one glob will in some cases
make gdb useless for some apps (fearless prediction).

Been there, done that, with IRIX/dbx and  'just virtual address
space' was a disaster for a few big apps with large value to
the owners/users (when the apps needed debugging).  Meaning we
did exactly what Eirik Fuller proposes and had to drop back to
exactly what Jim Blandy proposes.  [The problem was with 32 bit
address space of the debugger as it existed a few years ago.]

And  don't mmap in a whole core file for the same reason (not
that such is being proposed, this is just another thought).

David Anderson