From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18338 invoked by alias); 24 Aug 2010 01:06:50 -0000 Received: (qmail 18321 invoked by uid 22791); 24 Aug 2010 01:06:48 -0000 X-SWARE-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_BJ,TW_GJ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Aug 2010 01:06:43 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o7O16fJ2007977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 23 Aug 2010 21:06:41 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o7O16fd6023518; Mon, 23 Aug 2010 21:06:41 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o7O16elf031359; Mon, 23 Aug 2010 21:06:40 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 4CD3B3780C2; Mon, 23 Aug 2010 19:06:40 -0600 (MDT) From: Tom Tromey To: GDB Development Subject: Python API plans Date: Tue, 24 Aug 2010 01:06:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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-08/txt/msg00139.txt.bz2 Phil asked me to write up a list of the various Python projects that I think we should pursue in gdb. So, here it is; I welcome feedback, additions, etc. Don't expect many details here, it is really just the result of making notes whenever I missed something over the last couple of years. * Rebase and polish Oguz's inferior event work from the 2009 SoC. I think Oguz has started looking into this again. This functionality blocks a number of interesting Python uses; I think the event registry work is needed for some other (smaller) projects too. * Fix all open bugs. * Polish some of the existing commands and functions from the archer-tromey-python branch. Sub-tasks: * Finish the command-loading code. Time eager loading to see how expensive it is; if too expensive, write some lazy-loading wrappers. (We definitely do not want the "require" command from the branch.) * (See below for info on frame wrapper, new-backtrace, etc.) * Write Python wrappers for all MI commands, see: http://sourceware.org/bugzilla/show_bug.cgi?id=11688 This is an easy (-ish) way to provide a simple API to most of the relevant parts of GDB. * Generic command improvements. * Sometimes it would be nice to write a command with the same name as an existing command, but then delegate to the existing command (say, via a super call). * Likewise it would be nice if you could easily uninstall an overriding command. These considerations are why "new-backtrace" isn't just called "backtrace" -- if it has a bug the user is just stuck with it. Maybe just a "rename" facility is enough (or maybe just the existing alias.py plus deprecation -- worth looking at). * Breakpoint improvements: * Make it possible to create an internal breakpoint from Python. * Add a bit to breakpoints to make the breakpoint "maybe non-stopping" -- in the sense that when the breakpoint is hit, it will call an attached Python function, and if the function returns True, the breakpoint will not stop. This would be different from "commands" including "cont" in that it would not interfere with step or next. (You can fake this right now by doing work via a convenience function attached to the breakpoint condition -- but that is gross and user-visible.) * Use these two new features to write a command to create a "return" breakpoint. This is a breakpoint that fires when a function returns. (I think you can do this by putting a breakpoint at the function's entry, then going up and looking at the outer frame's PC, or something along those lines. Bonus points for interacting properly with longjmp and throw...) * Minimal systemtap integration. In particular I've been thinking it would be nice if gdb could read and use systemtap probe points. This doesn't have to be written in Python, but it seems like a nice experiment. Some sub-tasks: * Hooking into linespecs so users can write "probe:name" to refer to a systemtap probe. This would also mean dealing with completion, maybe some ugly linespec refactoring. * Let Python code access the contents of a section in an objfile. * Make a new Expression object that represents a parsed expression. Add a new gdb.parse method to create these, something like: gdb.parse (EXPR, [BLOCK], [STOP_AT_COMMA]) -> gdb.Expression This functionality is handy for writing certain kinds of commands. * Frame and "new-backtrace" cleanup * Clean up the frame wrapper and iteration code to solve problems reported on the Archer list; look at the various use cases posted there to make sure they can all be handled. This may mean adding more methods to Frame so we can avoid having a FrameWrapper at all. * Add a feature to new-backtrace to print the objfile name for a frame. (This might be a request in bugzilla somewhere.) * Rewrite the "upto" family of commands. They are ok but there were some ideas on the Archer list about how to improve them. * Give frame wrappers, or their replacement, some notion of being synthetic and having "original" sub-frames. The idea here is to provide multiple views of the stack, as a start toward debugging scripting languages. Provide versions of up/down/etc that work on the filtered view or the raw view, enhance new-backtrace to display sub-frames indented or something like that. Figure out how to present this via MI. * True scripting language debugging. This is a big goal that requires a lot of infrastructure, some already listed above. * Hook into linespecs so that "break x" can call into the scripting support code. * Hook into "watch" so the python code can do the right thing. * Hook into expression parsing. Maybe this could be done by letting people write new languages in Python. * Frame-based operations (up/down/etc) -- see above. * Hook into step/next/finish as needed. * New commands and functions I've wanted: * "log-expression". Like a combination between "break" and "printf", would trace expressions at some point in the code, without interfering with "next". (Needs at least the expression parsing stuff and a breakpoint enhancement.) * Finish "info mutex". The one posted to the list is a little dumb; it could be made more robust by using the systemtap probes in the mutex functions. With Oguz's work we would also have a way to look for deadlocks. * "declare $var : type" - make $var a reference to *(type*)malloc(sizeof(type)). I'm not sure this one is super useful, but it might make scripting gdb a little easier sometimes. * PR 8320, recursive version of "directory" command. * New function "$memoize". It would memoize strings in the inferior, so that they aren't constantly re-allocated. Useful when using a string in a breakpoint condition. This would need Oguz's work since the cache would have to be invalidated when the inferior is restarted. Tom