From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8824 invoked by alias); 20 Apr 2011 15:15:28 -0000 Received: (qmail 8811 invoked by uid 22791); 20 Apr 2011 15:15:27 -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, 20 Apr 2011 15:15:05 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p3KFF3fr007126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Apr 2011 11:15:04 -0400 Received: from localhost.localdomain (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p3KFF2aJ012798; Wed, 20 Apr 2011 11:15:03 -0400 From: Phil Muldoon To: Kevin Pouget Cc: gdb@sourceware.org Subject: Re: GDB Python API: stop/continue after breakpoint References: Reply-to: pmuldoon@redhat.com X-URL: http://www.redhat.com Date: Wed, 20 Apr 2011 15:15:00 -0000 In-Reply-To: (Kevin Pouget's message of "Wed, 20 Apr 2011 10:58:46 -0400") 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 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: 2011-04/txt/msg00112.txt.bz2 Kevin Pouget writes: > Hello, > > I'm coming back to this post because I've got a bit of an issue here: > > basically, I need (and I'm looking for to helping for it!) a sharp > control of the inferior execution from the python interface, but I'm > facing some limitations: > > * in MyBreakpoint.stop(), I can say continue/stop the inferior, but I > can't run "finish" (or "next" or what ever, I guess), because the > inferior is still considered as running: >> "gdb.error: Cannot execute this command while the selected thread is running." At this point GDB is deciding whether to stop the inferior and return control to the console or not. (Really, at this point, the inferior is stopped, by ptrace, but GDB is trying to work out if it should really maintain the stop, or resume the inferior). So in GDB's internal data store, the inferior (thread) is still "running" and will be so until a firm stop decision is reached. Because of this intermediate state, you cannot issue cannot step/next/continue/finish or other inferior control commands. This is really a very simplistic view of what is going on. I've glossed over a lot. > * in event.stop.connect() that's possible, but I can't > `gdb.execute("continue")' the execution because I would miss any > "non-python" reasons to stop (ie, a user-breakpoint, a signal ...) The only thing I can think to do here is set some of your own data in your Python module. Breakpoint.stop sets some flag or data, and the event.connect can pick up on that. But there are gaps in the API. File bugs, I look there daily. I hope this helped some! Cheers, Phil