Re: [PATCH] Use mmap for symbol tables

[Jim Blandy <jimb@red-bean.com>]

That's interesting.  Since GDB does make a complete pass through the
symbol information to build its partial symbol tables, I would have
expected that doing network I/O each time the scan touched a new page
would be horrible, latency-wise.  But from what you've said, it sounds
like the kernel recognizes there's a linear scan going on and starts
doing read-ahead, so you can do the network I/O in parallel with GDB's
processing.  Do I have that right?

I hadn't noticed that you'd mapped the data read-only.  That's an even
better way of dealing with GDB bugs.  It's nice to know we don't have
any of that sort.  :)

However, doesn't that mean that changes to the data by other processes
(say) would become visible to GDB?  What happens when you recompile
the program while GDB's running?

On 1/30/06, Eirik Fuller <eirik@hackrat.com> wrote:
> > 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.
>
> 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.  :-)

I know how that goes.  :)

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

I'm just concerned about wasting address space.  People these days do
have awfully big programs.  There are executables out there in the
gigabytes (cue lurkers to share their horror stories).