From: Tom Tromey <tromey@redhat.com>
To: <Paul_Koning@Dell.com>
Cc: <sivachandra@google.com>, <dje@google.com>, <gdb-patches@sourceware.org>
Subject: Re: [RFC - Python Scripting] New method Objfile.symtabs () - docs included
Date: Thu, 05 Apr 2012 18:41:00 -0000 [thread overview]
Message-ID: <87ehs2f2dk.fsf@fleche.redhat.com> (raw)
In-Reply-To: <09787EF419216C41A903FD14EE5506DD0313D5BF45@AUSX7MCPC103.AMER.DELL.COM> (Paul Koning's message of "Thu, 5 Apr 2012 11:30:05 -0500")
>>>>> "Paul" == <Paul_Koning@Dell.com> writes:
Paul> Those presumably live in a symtab but I didn't
Paul> see a gdb.Symtab method to get them. (Is that the right approach? I
Paul> can work on creating the machinery if this is the place for them, or
Paul> if someone can point me to where in the gdb.* class hierarchy to fit
Paul> this.)
Yes, I think adding the ability to iterate over symbols in a symtab is
the way to go.
Actually, what Siva said sounds good, aside from the lazy CU
instantiation issue:
Siva> The exploration of symbols to look for functions can happen in
Siva> this order: gdb.objfiles () => Objfile.symtabs () => Symtab.blocks
Siva> () => Block.symbol => Symbol.name.
Of course for your use, you won't care about lazy instantiation so much,
since you will be expanding them all anyway.
An extension to the earlier idea would be to make it possible to have
the iterator take a symbol name to search for as well. This would let
you instantiate many fewer CUs. This is more or less how the "quick"
symbol API works.
Tom
next prev parent reply other threads:[~2012-04-05 18:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-02 6:17 Siva Chandra
2012-04-02 17:08 ` Eli Zaretskii
2012-04-03 0:04 ` Doug Evans
2012-04-03 5:54 ` Siva Chandra
2012-04-05 16:30 ` Paul_Koning
2012-04-05 18:41 ` Tom Tromey [this message]
2012-04-05 18:37 ` Tom Tromey
2012-04-05 19:56 ` Paul_Koning
2012-04-05 20:26 ` Doug Evans
2012-04-06 16:42 ` Siva Chandra
2012-04-09 17:56 ` Tom Tromey
2012-04-09 17:59 ` Doug Evans
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=87ehs2f2dk.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=Paul_Koning@Dell.com \
--cc=dje@google.com \
--cc=gdb-patches@sourceware.org \
--cc=sivachandra@google.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