This is the mail archive of the archer@sourceware.org mailing list for the Archer project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Thu, 31 Jul 2008 21:02:46 +0200, Tom Tromey wrote:
> >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
> Thanks for this note.  It was very comprehensive.

Maybe it was just stupid from me to think it can be somehow incrementally
cheated by some obstack/xmalloc trick...


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


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

Please note that .debug_pubnames is a part of the DWARF3 spec.


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

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


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

IMO it is a heavy dig, psymtabs->symtabs resolving/lookups are scattered
across the code.  But there were some bugs in it so it should be done.


Thanks,
Jan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]