From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29751 invoked by alias); 11 Mar 2011 16:25:34 -0000 Received: (qmail 29732 invoked by uid 22791); 11 Mar 2011 16:25:31 -0000 X-SWARE-Spam-Status: No, hits=-6.0 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; Fri, 11 Mar 2011 16:25:26 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p2BGPOOY017515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Mar 2011 11:25:24 -0500 Received: from localhost.localdomain (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p2BGPM1p032731; Fri, 11 Mar 2011 11:25:23 -0500 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: Fri, 11 Mar 2011 16:25:00 -0000 In-Reply-To: (Kevin Pouget's message of "Fri, 11 Mar 2011 17:08:57 +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 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-03/txt/msg00088.txt.bz2 Kevin Pouget writes: > Hello, > > I've tried the GDB python interface today, which seems quite > efficient, but there is one important thing I couldn't figure out by > myself: > > how to restart GDB when a[n internal] breakpoint is hit ? > from the testsuite I've got this code: You almost can. One part is pending: http://sourceware.org/ml/gdb-patches/2011-03/msg00656.html The implementation of the "stop" API. The idea behind this is that if a breakpoint is hit, that is tracked from Python and has an implemented stop method, that method would be called. You can do what you like in that method. If you want the inferior process to continue, return True otherwise return False (and print out/do whatever else you need to do in Python). Because internal breakpoints are not tracked by default in the Python Breakpoint API, you would have to create your breakpoint by instantiating a gdb.Breakpoint class, and pass the keyword internal=True. So, long story short soon. OTOH I'm not sure if there is a unhacky way of doing it now. You could use a convenience function, but that patch is replacing that hacky way. Cheers Phil > > def breakpoint_stop_handler (event): > if (isinstance (event, gdb.StopEvent)): > print "event type: stop" > if (isinstance (event, gdb.BreakpointEvent)): > print "stop reason: breakpoint" > print "breakpoint number: %s" % (event.breakpoint.number) > if ( event.inferior_thread is not None) : > print "thread num: %s" % (event.inferior_thread.num); > else: > print "all threads stopped" > > gdb.events.stop.connect (breakpoint_stop_handler) > > > which where I get the notification of the stop, but I'd to be able to > tell GDB something like > > enum bpstat_what_main_action { > /* Remove breakpoints, single step once, then put them back in and > go back to what we were doing. It's possible that this should > be removed from the main_action and put into a separate field, > to more cleanly handle BPSTAT_WHAT_CLEAR_LONGJMP_RESUME_SINGLE. */ > BPSTAT_WHAT_SINGLE, > /* Stop silently. */ > BPSTAT_WHAT_STOP_SILENT, > > /* Stop and print. */ > BPSTAT_WHAT_STOP_NOISY, > ... > } > > to continue silently, stop silently or print the breakpoint hit. > > is it possible at this stage ? > > Thanks, > > Kevin