From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8761 invoked by alias); 27 Jan 2010 19:27:12 -0000 Received: (qmail 8750 invoked by uid 22791); 27 Jan 2010 19:27:12 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-iw0-f193.google.com (HELO mail-iw0-f193.google.com) (209.85.223.193) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 27 Jan 2010 19:27:07 +0000 Received: by iwn33 with SMTP id 33so527184iwn.0 for ; Wed, 27 Jan 2010 11:27:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.151.207 with SMTP id d15mr508856ibw.44.1264620425223; Wed, 27 Jan 2010 11:27:05 -0800 (PST) Date: Wed, 27 Jan 2010 19:27:00 -0000 Message-ID: Subject: Python API problems From: Joseph Garvin To: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-01/txt/msg00198.txt.bz2 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.