Re: Frames as scopes

[Thiago Jung Bauermann <bauerman at br dot ibm dot com>]

El jue, 01-01-2009 a las 09:47 -0700, Doug Evans escribiÃ:
> On Tue, Dec 30, 2008 at 2:57 PM, Jim Blandy <jimb@red-bean.com> wrote:
> > I've been having a great time playing with the Python interface!
> >
> > On IRC, Tom invited me to post suggestions.
> >
> > Is there a way to look up a variable in the scope specified by a frame?  Saying
> >
> >    gdb.lookup_symbol('argc',gdb.block_for_pc(gdb.current_frame().pc()),gdb.SYMBOL_VAR_DOMAIN)
> >
> > seems circuitous; perhaps lookup_symbol could default the domain to
> > SYMBOL_VAR_DOMAIN, and accept a frame to indicate scope, defaulting to
> > the current frame.  Then one could simply say:
> >
> >    gdb.lookup_symbol('argc')
> >
> > and get what one expects.

Default to current_frame or to selected_frame? I tend to prefer the
later, but I don't know which one would be better as a default. Apart
from that, I think the defaults you mention are a good idea.

Also, the construction gdb.block_for_pc
(gdb.{current,selected}_frame().pc() occurs rather frequently. I have a
line like that in in_scope.py as well. A block() method to gdb.Frame
would be a good idea.

> Another way to go is to have wrappers that simplify common operations
> as part of some utility library (or some such).  Low level api
> routines shouldn't be too clever.

I agree with that, but the downside is that the utility library would be
yet another API to invent and support. I don't feel enthusiastic about
that...

But I don't oppose the idea. If folks post patches with Python code
saying 'hey, this function/module I made really helped me, can we
include it in gdb proper?', more power to them.
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center