Re: Frames as scopes

["Jim Blandy" <jimb at red-bean dot com>]

On Fri, Jan 2, 2009 at 6:14 PM, Thiago Jung Bauermann
<bauerman@br.ibm.com> wrote:
> 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.

You're right, selected_frame is better --- its whole reason for
existence is to provide a default frame for things. :)

> 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.

Beautiful.

>> 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.

Having a library of friendly wrappers for the basic operations seems
ungainly.  Our audience is scripters, so the primary API should be
friendly.

Perhaps unfriendly primitives (implemented in C) would live in a
separate module (gdb.primitives), and then friendly Python
functions/classes based on them would live in the gdb module.  The
latter would be the only documented, supported interface.