From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23651 invoked by alias); 27 Jun 2011 08:52:28 -0000 Received: (qmail 23641 invoked by uid 22791); 27 Jun 2011 08:52:27 -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; Mon, 27 Jun 2011 08:52: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 p5R8puxi017602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 27 Jun 2011 04:51:56 -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 p5R8ptbc003482; Mon, 27 Jun 2011 04:51:55 -0400 From: Phil Muldoon To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: more OO, use breakpoints_ops for all kinds of breakpoints (Re: [patch] [python] Expose some breakpoint operations to Python) References: <201106231804.26462.pedro@codesourcery.com> <201106241741.20442.pedro@codesourcery.com> Reply-to: pmuldoon@redhat.com X-URL: http://www.redhat.com Date: Mon, 27 Jun 2011 08:52:00 -0000 In-Reply-To: <201106241741.20442.pedro@codesourcery.com> (Pedro Alves's message of "Fri, 24 Jun 2011 17:41:20 +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/msg00389.txt.bz2 Pedro Alves writes: >> I'd like to finish that conversion soon. Thanks for the patch! > I did a bit more work on this. Watchpoints were already using > breakpoint_ops. I added a bkpt_breakpoint_ops for all software/hardware > breakpoints, and a tracepoint_ops for all kinds of tracepoints, > and moved the default actions to the appropriate places. There > were places where I could cleanup a bit further, but I figured > I'd better do those as follow ups. I think these 4 major > kinds of "breakpoints" is already a good start. Further > refinement could split internal / momentary breakpoints > into its own ops, for example. I've not converted my Python patch to use this yet, but it looks like it would be fairly simple. FWIW, I think this is great. > I left behind the print_one method, as that seems will > require something else, or some disentanglement. I don't have the file open at this moment, but if I remember correctly this is the callback that can fail with breakpoints that have multiple locations? If we could convert that assert() to an error() I could catch it and deal with it. If I remember correctly, asserts do not propagate through the exception framework as normal GDB errors, so we would have to do something here to let the Python code manage this error? Generally, as a side point, asserts are somewhat the bane of my life especially if they do not indicate fatal GDB situations. > The current insert/remove abstration is at raw location level. > We can't use it as is to split insert_bp_location. We may need > to rename the current methods to e.g., insert_raw_location (or > move them to the bp_location vtable), and add new breakpoint_ops > methods that call the raw methods, and, handle the different > warnings and insert-failed->revert paths as appropriate per > breakpoint type. Sounds good to me. I was thinking on this from the Python side, when (if) we finally propagate this functionality to the API. Right now I do not see how we could abstract these functions enough (into a more discrete GDB-side API) to allow the Python user to use them safely. It seems to require an awful lot of internals from GDB to make accurate decision, and I am a little uncomfortable with allowing this level of introspection from the Python side. On could argue this allows for a deeper, more powerful API, but there is a risk that internals could change that would force a Python API break. Anyway, I ramble on ... I think your logic is sound with the baser more raw callbacks. > > This has no regressions for me. It misses some comments and > cosmetics here and there, and a ChangeLog entry. I'll try to > get back to this soon, but I've got other fish to fry at > the moment. Thanks for doing this. I do not see any regressions either. Cheers, Phil -- Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson (USA), Charlie Peters (USA)