From: Siva Chandra <sivachandra@google.com>
To: Doug Evans <dje@google.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC - Python Scripting] New method Objfile.symtabs () - docs included
Date: Tue, 03 Apr 2012 05:54:00 -0000 [thread overview]
Message-ID: <CAGyQ6gwwnySK=2hxRj9fWDsxKt0Vqan7O_Lb3hrQt7gX7Me1SA@mail.gmail.com> (raw)
In-Reply-To: <CADPb22SLyHU2NUXuOWSOdqUHDA0NeFgiCZX-GWC5aqwhFvZn0w@mail.gmail.com>
On Tue, Apr 3, 2012 at 5:34 AM, Doug Evans <dje@google.com> wrote:
>
> You're touching on one of the more troublesome areas of gdb (symbol
> handling), I salute your courage. :-)
I seem courageous as I do not know what awaits me. :-)
> Assuming we want to provide the ability to iterate over all the symbol
> tables, we want to be able to do that without first expanding them.
> So I think the first question is what will the user want to do with
> this feature?
Thanks for taking a look and starting a discussion on this. An
example usage of this feature can be to implement something like run
time code path tracer. This can probably be done in many other ways,
but I am using this as an example. In this code path tracer, a user
might want to trace the function calls when between state A and state
B of program. A way to do this from Python would be to get all the
function names and set internal breakpoints at these functions. But
the user should first have a way to get the list of functions. This
is where I thought the Objfile.symtabs becomes useful - The
exploration of symbols to look for functions can happen in this order:
gdb.objfiles () => Objfile.symtabs () => Symtab.blocks () =>
Block.symbol => Symbol.name. This patch adding Objfile.symtabs () was
first of my patches towards completing this path.
Looking at it more generically, I thought that having the exploratory
path that I mention above available in the Python API completes a
'view' of GDB from a user's point.
For the memory problem you point out, do you think something like
Objfile.symtabs (regex, [symbol_type]) would be good? REGEX is a file
name matcher to specify that only those symtabs whose source file
names match the REGEX should be loaded, and SYMBOL_TYPE is to specify
that only symbols of this kind should be loaded. This can still be
abused to match everything and load everything, but it is at the
user's own peril.
Thanks,
Siva Chandra
next prev parent reply other threads:[~2012-04-03 5:54 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 [this message]
2012-04-05 16:30 ` Paul_Koning
2012-04-05 18:41 ` Tom Tromey
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='CAGyQ6gwwnySK=2hxRj9fWDsxKt0Vqan7O_Lb3hrQt7gX7Me1SA@mail.gmail.com' \
--to=sivachandra@google.com \
--cc=dje@google.com \
--cc=gdb-patches@sourceware.org \
/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