This is the mail archive of the
mailing list for the GDB project.
Re: Python API problems
Also, being able to know the thread number for the current frame would
be useful for writing commands that keep state associated with each
On Wed, Jan 27, 2010 at 1:27 PM, Joseph Garvin
> 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
> 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