From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23023 invoked by alias); 23 Jun 2011 17:04:43 -0000 Received: (qmail 23013 invoked by uid 22791); 23 Jun 2011 17:04:42 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 23 Jun 2011 17:04:29 +0000 Received: (qmail 32560 invoked from network); 23 Jun 2011 17:04:28 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 23 Jun 2011 17:04:28 -0000 From: Pedro Alves To: gdb-patches@sourceware.org, pmuldoon@redhat.com Subject: Re: [patch] [python] Expose some breakpoint operations to Python Date: Thu, 23 Jun 2011 17:04:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic; KDE/4.6.2; x86_64; ; ) References: <201106231629.39370.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201106231804.26462.pedro@codesourcery.com> 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/msg00360.txt.bz2 On Thursday 23 June 2011 16:56:50, Phil Muldoon wrote: > Pedro Alves writes: > > > On Thursday 23 June 2011 15:46:14, Phil Muldoon wrote: > > > No plan yet. I just started out by adding a single breakpoint_ops instance > > that handles all breakpoint types that currently aren't using breakpoint_ops, > > and moving all default actions to the corresponding callback. This would > > be straightforward if the API is a good fit. But take a look at > > the fallback code in print_one_breakpoint_location, and print_one_breakpoint. > > Breakpoints with multiple locations are handled a bit differently than > > just a fallbach, with multiple calls to print_one_breakpoint. Maybe > > we could move all that !print_one code inside the new print_one > > callback? > > 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); } > 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. -- Pedro Alves