Re: Python API problems

[Joseph Garvin <joseph.h.garvin@gmail.com>]

Also, being able to know the thread number for the current frame would
be useful for writing commands that keep state associated with each
thread.

On Wed, Jan 27, 2010 at 1:27 PM, Joseph Garvin
<joseph.h.garvin@gmail.com> wrote:
> I was quite excited to see that gdb 7.0 added python scripting and so
> tried to implement a few ideas. Unfortunately, under the current API,
> none of them are possible AFAICT. It's possible others have pointed
> out these issues already but I thought I'd share them here in case the
> developers were interested in knowing what people are trying with the
> API and what issues they're running into.
>
> I wanted to be able to wildcard break on all the functions in a
> particular C++ scope, so if I had a namespace called 'foo' I could do
> this:
>
> break foo::*
>
> And any functions in the foo namespace would receive breakpoints. So I
> attempted to code an alternative version of break called 'starbreak'
> that would do this. Issues I ran into:
>
> -None of gdb's standard commands are exposed directly. You have to
> create strings and pass them in to gdb.execute. gdb.execute doesn't
> have a return value, so you can't get back any information from
> commands. If break were exposed as a python function for example, it
> could return a breakpoint object on which you could later in the
> python code call enable/disable, or inspect to see what address or
> line number was broken at (if for example you broke by function name).
>
> -There's a lookup_type but not a more general lookup_symbol. It'd be
> nice if such a function existed. Also, search_type and search_symbol
> for matches to a regex.
>
> -That could be worked around if gdb.execute returned a string
> containing what information would otherwise have gone to the console.
> Then we could at least parse the output. This would be nice in general
> for working around API holes until they're filled. Because of this I
> can't even manually search the output from "info functions" (though
> searching that would be slooooooow).
>
> -You can't call the builtin completion functions. Basically I'd like
> to call complete_symbols("foo::", "") to get a list of symbols in the
> foo namespace, then iterate through them and break on each one. If in
> my constructor I pass in gdb.COMPLETE_SYMBOL, I would expect then if I
> call the base class version of complete, e.g.
> gdb.Command.complete(self, "foo::", "") I would get back the results
> of the builtin version of complete. But I don't, complete is not
> defined. This doesn't feel very pythonic.
>
> -Needing to pass the name of the class to the constructor is silly.
> Python has reflection facilities (see the 'inspect' module), gdb
> should be able to inspect the class and figure out its name itself.
>
> -Needing to manually instantiate an instance of the class *may be*
> silly. Python's reflection could be used to look at the imported
> classes and make instantiations of any classes defined to inherit from
> gdb.Command. On the other hand, real pythonistas might be able to
> conjure some hack that depends on commands being instantiated in an
> order they define, so this isn't necessarily a good idea, but I can't
> think of why someone would want to do that off the top of my head at
> least.
>