Re: can pahole print a struct definition in a given CU?

[Doug Evans <dje@google.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.