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

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> As promised on #tools giving some info what I have found.  I am
Jan> talking specifically only about the loading of the .debug
Jan> (separate debug info files) from disk (I do not know about other
Jan> runtime performance problems).

Thanks for this note.  It was very comprehensive.

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.

What if we modify GCC to emit a new .debug_privnames with the missing
data?

I tried enabling the debug_pubnames code.  I needed a couple little
patches to make it compile and not crash... according to gprof it is
much faster (from 30 seconds down to 5 seconds) but it also used a lot
more memory (hitting swap, so subjectively it was extremely slow :).
So, something is a bit rotted here and at least needs a cleanup.

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.


I'm still digesting the rest of your note.

thanks,
Tom