From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32410 invoked by alias); 24 Aug 2010 09:39:11 -0000 Received: (qmail 32402 invoked by uid 22791); 24 Aug 2010 09:39:10 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,TW_GJ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp.nokia.com (HELO mgw-mx09.nokia.com) (192.100.105.134) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Aug 2010 09:38:59 +0000 Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o7O9cosq000718 for ; Tue, 24 Aug 2010 04:38:57 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Aug 2010 12:38:52 +0300 Received: from mgw-da02.ext.nokia.com ([147.243.128.26]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Aug 2010 12:38:51 +0300 Received: from gar.localnet (berwst16747.europe.nokia.com [172.25.167.47]) by mgw-da02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o7O9cnm5019363 for ; Tue, 24 Aug 2010 12:38:49 +0300 From: =?iso-8859-1?q?Andr=E9_P=F6nitz?= To: gdb@sourceware.org Subject: Re: Python API plans Date: Tue, 24 Aug 2010 09:39:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.32-21-generic; KDE/4.4.2; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201008241138.46655.andre.poenitz@nokia.com> X-Nokia-AV: Clean 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-08/txt/msg00140.txt.bz2 On Tuesday 24 August 2010 03:06:40 ext Tom Tromey wrote: > 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; Puh, that's quite a bit. > 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. >=20 > * 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. I think inferior interaction (run/stop stuff) and breakpoint access are the= =20 big "missing" areas in Python support. From a frontend's point of view the missing "run control" is actually not that bad as it is sufficiently=20 well supported by MI (in contrast to breakpoints), but from a CLI/Python user's point of view the priorities are probably inverted. > * Fix all open bugs. I am not sure whether e.g. http://sourceware.org/bugzilla/show_bug.cgi?id=3D10790 really deserves a "Pythonic fix" as long as there are real problems around that don't have obvious (if any) workarounds. =20 > * Polish some of the existing commands and functions from the > archer-tromey-python branch. Sub-tasks: >=20 > * 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.) >=20 > * (See below for info on frame wrapper, new-backtrace, etc.) >=20 > * Write Python wrappers for all MI commands, see: >=20 > http://sourceware.org/bugzilla/show_bug.cgi?id=3D11688 >=20 > This is an easy (-ish) way to provide a simple API to most of the > relevant parts of GDB. Similar here. The effective gain seems limited, especially since quite a bit of the MI commands are not optimal themselves. As a really awful example: "-data-read-memory" produces a lot of unneeded "information" yet is so slow that a "dump binary memory"/read-from-file combination easily beats it by a factor of two or three. That behaviour should not=20 be wrapped in Python. I could imagine handling that item on a case-by-case base and spending an extra thought or two on each individual API might make more sense. > * Generic command improvements. >=20 > * 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). >=20 > * Likewise it would be nice if you could easily uninstall an > overriding command. >=20 > 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). I have no opinion on these. > * Breakpoint improvements: >=20 > * Make it possible to create an internal breakpoint from Python. >=20 > * 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.) I haven't looked at Python breakpoint handling for a while, MI is certainly missing feedback about multiple breakpoints, and gdb as a whole seems to be missing some user visible feedback when pending breakpoints. > * 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...) Maybe the issue discussed in http://cygwin.ru/ml/gdb/2010-03/msg00116.html could be resolved in the way "everybody" expects, too? ;-) > [snip]=20 > * Let Python code access the contents of a section in an objfile. That would be nice indeed. =20 > * Make a new Expression object that represents a parsed expression. > Add a new gdb.parse method to create these, something like: >=20 > gdb.parse (EXPR, [BLOCK], [STOP_AT_COMMA]) -> gdb.Expression >=20 > This functionality is handy for writing certain kinds of commands. What's the use case? Keeping "anything" on the inferior side? > [snip] > * "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. I have a similar construct five times in my code (creating an initialized gdb.Value, but that 'declare' is the first step) I think having it handled in gdb would be nice, especially if it relieves me from figuring out when to add 'class ' to the type, and when to quote it etc to 'survive' gdb command line parsing. Another open issue in the area is to provide a way to keep (structure) return values of inferior calls alive in the inferior. Right now the only w= ay=20 I am aware of to chain or nest inferior calls is to poke data back manually. =46rom a quick glance, http://sourceware.org/bugzilla/show_bug.cgi?id=3D11914 http://sourceware.org/bugzilla/show_bug.cgi?id=3D10344 seem to be related. > * PR 8320, recursive version of "directory" command. That's not solvable using "set substitute-path"? But anyway, it would be nice if gdb was able to tell the user that it did not find a file, or that it had to guess and is not sure the guess is right, and ideally even provide some means to query for user advice in that situation. Looks like you have a lot of work ahead. Andre'