From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14024 invoked by alias); 20 Apr 2011 15:20:28 -0000 Received: (qmail 14016 invoked by uid 22791); 20 Apr 2011 15:20:27 -0000 X-SWARE-Spam-Status: No, hits=-6.9 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:20:05 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p3KFK3rX009692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Apr 2011 11:20:03 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p3KFK3ZR031295; Wed, 20 Apr 2011 11:20:03 -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 p3KFK2CU001520; Wed, 20 Apr 2011 11:20:02 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 06A19378091; Wed, 20 Apr 2011 09:20:01 -0600 (MDT) From: Tom Tromey To: Kevin Pouget Cc: gdb@sourceware.org Subject: Re: GDB Python API: stop/continue after breakpoint References: Date: Wed, 20 Apr 2011 15:20:00 -0000 In-Reply-To: (Kevin Pouget's message of "Fri, 11 Mar 2011 18:52:19 +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: 2011-04/txt/msg00113.txt.bz2 >>>>> "Kevin" == Kevin Pouget writes: Sorry, I didn't notice this until your follow-up. Kevin> thanks for your answer, the patch seems to feature what I was Kevin> looking for. I'm a bit surprised that the stop/continue decision Kevin> can't be done in this breakpoint_stop handler, but I guess that Kevin> was too complicated ? We intentionally made event handlers not return values. My recollection is that this was done both due to simplicity and also out of the desire to make it clear that event handlers ought to be logically separate. Once handlers affect other handlers, the coding gets more complicated, and it seems better to associate such actions more directly with their causes. Tom