This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: can pahole print a struct definition in a given CU?
- From: Doug Evans <dje at google dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Tristan Su <sooqing at gmail dot com>, gdb <gdb at sourceware dot org>
- Date: Wed, 2 Jan 2013 11:56:35 -0700
- Subject: Re: can pahole print a struct definition in a given CU?
- References: <CA+sbV4jqL=6=MV891x8tL0SvFAJno5x7PxRxTULtmsb0tVkZPA@mail.gmail.com> <87fw2j5w4y.fsf@fleche.redhat.com>
On Wed, Jan 2, 2013 at 10:31 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Tristan" == Tristan Su <sooqing@gmail.com> writes:
>
> Tristan> I found pahole (python api) quite useful but jusst could not have it
> Tristan> print a struct in a given compilation unit.
> Tristan> With the ptype command:
> Tristan> (gdb) ptype S
> Tristan> but we can also specify the CU because the struct may have different
> Tristan> define in different CUs.
> Tristan> (gdb) ptype 'foo.c'::S
>
> Tristan> Is that possible/easy to make pahole support this?
>
> I couldn't think of an easy way. Though maybe that is just imagination
> failure on my part :)
>
> If I were doing this I would start by finding a way to expose
> evaluate_type to Python, say via a flag to parse_and_eval.
> Then I would make pahole use this.
I realize we're talking about types here, but there's a general
problem here, and there's another approach to choosing object foo from
source bar.c. [This doesn't immediately help with the pahole issue
here, but it's a thought that occurred to me, so I'm writing it down.]
It's seems like what's needed is a handle on the symtab(CU), and then
a way to go from there, instead of encoding the symtab in the
expression.
Since expressions in the source work that way, making things like "p
'bar.c'::foo + 'baz.c'::foo" work seems like excessive generality.
[For completeness sake, I realize that works today and we can't break
it. Still, I think there's room for improvement.]
Thus,
what about adding a "context" parameter to parse_and_eval, etc.?
And then provide a way to specify that context (e.g., both from the
CLI and from Python).
We'd still have to support "p 'bar.c'::foo + 'baz.c::foo'", but when,
e.g, cut-n-pasting expressions from source we shouldn't have to force
the user to insert 'bar.c::' in front of objects that gdb might end up
otherwise picking the wrong one for.
E.g., something like: (gdb) with-symtab bar.c p foo+baz
or whatever.