From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15718 invoked by alias); 25 Aug 2010 16:41:51 -0000 Received: (qmail 15707 invoked by uid 22791); 25 Aug 2010 16:41:48 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,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; Wed, 25 Aug 2010 16:41:43 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o7PGfffV023587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 25 Aug 2010 12:41:42 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o7PGffqD022896; Wed, 25 Aug 2010 12:41: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 o7PGfesY015639; Wed, 25 Aug 2010 12:41:40 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id BACA23780C2; Wed, 25 Aug 2010 10:41:39 -0600 (MDT) From: Tom Tromey To: Phil Muldoon Cc: GDB Development Subject: Re: Python API plans References: <4C753A8C.3060602@redhat.com> Date: Wed, 25 Aug 2010 16:41:00 -0000 In-Reply-To: <4C753A8C.3060602@redhat.com> (Phil Muldoon's message of "Wed, 25 Aug 2010 16:45:16 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) 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/msg00149.txt.bz2 >>>>> "Phil" == Phil Muldoon writes: Phil> There are two areas I would like to see improved beyond the initial Phil> patch. I have no opinion whether these can be incrementally improved Phil> after submission, or if we should hack on them first. These look good. I think it is a good idea for the first commit of a few feature to be as "API-complete" as we can make it: that is, we should try to reduce the number of future changes to which a user must adapt. E.g., changing the return type of a method is hard to adapt to, but adding a new method to a class is easy to adapt to. In this particular case, I think it is best to try to make the events as expressive as possible first; but the details of how events are implemented (Python or C) are not important provided they are future-proof. Phil> I agree about the eager loading. It might amount to nothing at all. Phil> If it does turn out to be expensive, what about having commands Phil> register themselves against a global Python list? This would be Phil> similar to how pretty-printers work. We could defer loading until the Phil> command is needed, but still (with some alteration to the completion Phil> code) allow the user to see the command-list in 'help 'and make the Phil> commands available for tab-completion? I think there is a simpler way that we could try first: http://sourceware.org/ml/gdb-patches/2010-07/msg00201.html This wouldn't require any changes to the gdb core. Tom> * Sometimes it would be nice to write a command with the same name as Tom> an existing command, but then delegate to the existing command (say, Tom> via a super call). Phil> Do you mean purely Python commands overriding other Python commands, or Phil> in-built commands as well? I meant built-in commands, but being generic would not be bad. Phil> I'm not sure if you can run arbitrary Python code in a condition Phil> though (i.e., .condition("python if somePythonFunction() == Phil> True"). Yeah, you can via a convenience function. That is pretty ugly though. Phil> Ideally I'd like the Python API to be fully aware of the state of the Phil> inferior. On the flip-side I'd also to be able to control the Phil> inferior in a more atomic way than issuing gdb.execute("step") Phil> commands and guessing if the inferior did as expected. The dreaded MI wrappers would achieve this ;-) I'm mildly concerned about writing a bunch of wrappers for these commands that work either synchronously or asynchronously, depending on the non-stop setting. It seems like it would be preferable to make them always async, with some kind of completion hook. But, I think that may require a big gdb change, like always enabling non-stop or something along those lines. So, I think we should defer explicit support for step/next/etc until we have a bit more clarity about long term goals here. (I don't really consider the MI wrapper project as "explicit" -- since that is more like, do one change and get a bunch of stuff "for free", even if some of what you get is useless or doesn't really make sense.) Phil> * Python breakpoints to support 'catch' breakpoints (especially the Phil> system-call variety). Sounds good. Phil> * Make it so that tab completion knows about Python API Phil> completions. So (gdb) gdb. would list all of the available Phil> Python bits associated with the GDB module. Make this lower priority. It might be nice to have but I think basic functionality is more important. Phil> * Python representation of a target. I think the note on the wiki was about letting people write new targets in Python. This might be interesting but I think it is a very low priority. If there are parts of the target or gdbarch that are needed for generic scripting stuff, then we should export those via some read-only interface. Phil> * Allow Python scripts to control start-up of GDB so it allows the Phil> equivalent of gcore like commands. I pushed this kind of scripting/tracing idea for a while. And, I do still like it. But I also think that, for us, systemtap fills the non-interactive tracing role quite well. So, I think we should focus more on gdb's interactive functionality. I'd like to do some deeper systemtap integration with gdb, too, but that isn't on this list since it isn't related to Python. Tom