From: Tom Tromey <tromey@redhat.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: Paul Hilfinger <hilfinger@adacore.com>, gdb-patches@sourceware.org
Subject: Re: RFC: lazy partial symbol table reading
Date: Mon, 20 Jul 2009 21:36:00 -0000 [thread overview]
Message-ID: <m3d47vi1i4.fsf@fleche.redhat.com> (raw)
In-Reply-To: <20090326011605.GJ9472@adacore.com> (Joel Brobecker's message of "Wed\, 25 Mar 2009 18\:16\:05 -0700")
>>>>> "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
prev parent reply other threads:[~2009-07-20 19:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-24 0:31 Tom Tromey
2009-03-25 22:33 ` Joel Brobecker
2009-03-25 23:56 ` Tom Tromey
2009-03-26 1:24 ` Joel Brobecker
2009-07-20 21:36 ` Tom Tromey [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3d47vi1i4.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=hilfinger@adacore.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox