Python API problems

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

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.