Re: FYI GDB on-disk .debug cache (mmapcache) [Re: Tasks]

[Daniel Jacobowitz <drow at false dot org>]

On Thu, Jul 31, 2008 at 09:22:18PM +0200, Jan Kratochvil wrote:
> > Jan> dwarf2_build_psymtabs_easy() should have been using the index
> > Jan> sections like `.debug_pubnames' but GDB has it #if 0-ed.  IIRC
> > Jan> GDB currently builds its psymtab entries even for `static'
> > Jan> variables across files while the C semantics says these are not
> > Jan> visible.  `.debug_pubnames' correctly does not contain the
> > Jan> `static' variables making dwarf2_build_psymtabs_easy() either
> > Jan> impossible or changing the current GDB behavior.
> > 
> > I'm reluctant to change gdb behavior for something like this; I assume
> > that users would complain.  I'm not absolutely opposed, though.
> 
> It is already related to resolve a name in multiple files, currently not being
> solved in HEAD.  What if it is also a local nested function?  Do we always
> want to silently hide the definitions outside of the local block?

In my experience, the most important case are static
variables/functions whose names are actually unique across the
program.  This happens a lot and it's convenient that GDB knows what
you're referring to right away.

> Just a question if psymtabs are enough?  IMO sooner or later symtabs get
> loaded but I have no benchmarks for it.  I would find best to run asynchronous
> --readnow during the startup (when we have the asynchronous GDB mode now).

There's a command, maint print statistics, which can show you how many
unexpanded psymtabs there are and how many were expanded into full
symtabs.  It should not be too hard to collect data if you can manage
some "typical" debugging sessions - for instance a couple of "bt full"
in firefox or OOo.

> > Jan> Daniel J. did suggest that psymtab+symtab should be encapsulated
> > Jan> for the GDB core and left as an implementation detail for the
> > Jan> debuginfo backend (DWARF).
> > 
> > If this is what we want, how much work is it?
> > Only answer if you know offhand -- if you don't, I can look a bit.

A lot.  This is one of the areas I was talking to you about before; it
would benefit GDB to have clean and obeyed abstractions, but what we
have now is anything but.  It's possible to incrementally improve the
situation, any time someone wants to take a whack at it.

-- 
Daniel Jacobowitz
CodeSourcery