Re: RFC: lazy partial symbol table reading

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

I was merging the trunk to this branch today, and wondered whatever
happened with this conversation...

Joel> I think I need to discuss the principle of this patch internally with
Joel> the other AdaCore GDB engineers, in particular with Paul Hilfinger.

[...]

Joel> Basically, what I'm worried about is creating a big pause once
Joel> the debugging session has started. For instance, if the user tries
Joel> to print the value of variable that's not found in the local scope
Joel> (basically, a global variable), the next thing we do is search all
Joel> symbols in all symtabs/psymtabs. Or even more common: Inserting
Joel> a breakpoint on a function ("break function_name"). Again, we search
Joel> all symtabs/psymtabs.  This is necessary, because we need to handle
Joel> homonyms.

Yes, this is a problem, even for C.

My canonical test case is attaching to a running OO.o Writer process,
with all debuginfo installed.  This patch greatly speeds up the initial
attach.  If I do "thread apply all bt full", this is also reasonably
speedy -- but there is one particular point at which there is a long
pause while gdb reads debuginfo.

I looked a little bit into reading some debuginfo in the background.  My
idea was that gdb would spawn a worker thread to process only the
largest debuginfo, because that is more likely to be needed and also
because it is more likely to cause a noticeable pause when it is read.
This turns out to be a bit involved, and since it was really a Plan B
idea for me I dropped it.

Joel> If we have a way of having all symbol names available without creating
Joel> the symtabs (the .debug_pubnames section), then I think we have the cake
Joel> and eat it too: We only have to create the psymtab for the CUs that
Joel> we need. In fact, one could argue that we actually no longer need
Joel> the partial symtab anymore...

Yeah.  I'd also like to parse just single CUs and also get rid of
partial symbol tables when using DWARF.

I think this is Plan A to fix this problem.  My understanding (I think
based on comments I've seen or email messages in the archives) is that
this is a direction desired by other gdb maintainers as well.  I haven't
looked to see how much work it really is, though.

pubnames are difficult at the moment because gcc has pubname generation
bugs.  So, we can't rely on the contents of this section.  And even once
gcc is fixed... how will we know we can rely on it then?

Also gcc only just started generating pubtypes (except on Mac OS, where
it has done so for a while).

Finally, there's the private names issue I mentioned upthread.
One solution is to also emit debug_privnames and debug_privtypes
(needed?) for gdb's use.

I'm hoping to get somebody here at Red Hat to fix the gcc problems.
But, I don't know when.

Tom