From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20172 invoked by alias); 23 Jun 2011 18:58:35 -0000 Received: (qmail 20164 invoked by uid 22791); 23 Jun 2011 18:58:35 -0000 X-SWARE-Spam-Status: No, hits=-6.2 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; Thu, 23 Jun 2011 18:58:21 +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 p5NIwCCJ019984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Jun 2011 14:58:12 -0400 Received: from localhost.localdomain (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p5NIwAwM031045; Thu, 23 Jun 2011 14:58:11 -0400 From: Phil Muldoon To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [patch] [python] Expose some breakpoint operations to Python References: <201106231629.39370.pedro@codesourcery.com> <201106231804.26462.pedro@codesourcery.com> Reply-to: pmuldoon@redhat.com X-URL: http://www.redhat.com Date: Thu, 23 Jun 2011 18:58:00 -0000 In-Reply-To: <201106231804.26462.pedro@codesourcery.com> (Pedro Alves's message of "Thu, 23 Jun 2011 18:04:26 +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-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-06/txt/msg00361.txt.bz2 Pedro Alves writes: > On Thursday 23 June 2011 16:56:50, Phil Muldoon wrote: >> Yes the multiple locations thing is a bit weird. But from (my Python) >> point of view, that is an internal abstraction that the Python glue code >> will absorb. I don't think this will affect Python API users too much. > > What happens if you create a python breakpoint that ends up > with multiple locations? Don't you end up tripping on this > assertion? > > /* 5 and 6 */ > if (b->ops != NULL && b->ops->print_one != NULL) > { > /* Although the print_one can possibly print all locations, > calling it here is not likely to get any nice result. So, > make sure there's just one location. */ > gdb_assert (b->loc == NULL || b->loc->next == NULL); > b->ops->print_one (b, last_loc); > } Well to be fair, any breakpoint that implements breakpoint_ops will (including catchpoints). I guess the point there is that they won't, or are not likely to encounter this. Fair point. Actually I should have tested for this very scenario, so I will add it to the Python tests. What we could do is if a breakpoint has multiple locations just don't call this routine, or alter the logic to raise something less aggressive than an assert. But you have convinced me that breakpoint ops need a good going over. Any function, internal or external, that lets the user create a perfectly legitimate breakpoint, then later causes GDB to give up, because it does not how to handle it is bogus. >> But I take your point. I'm trying to position this patch so that users >> can access a limited subset of printing breakpoint operations. The >> time-line is important here too. If this refactoring internally is just >> going to take a few weeks, hey, no big deal, I can just wait and >> adjust. But if it is a long term thing, I think we could expose the >> limited functionality we expose now. > > I'd like to finish that conversion soon. I really look forward to it! In the meantime I will check-in the patch to a git branch on archer, and keep it updated. If the breakpoint ops refactoring turns into a deep-dark hole, we can always later do something like the above in solving it. Cheers, Phil