From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5350 invoked by alias); 9 Feb 2012 12:56:58 -0000 Received: (qmail 5122 invoked by uid 22791); 9 Feb 2012 12:56:56 -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; Thu, 09 Feb 2012 12:56:35 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q19CuVK7015278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Feb 2012 07:56:32 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q19CuU9s009591; Thu, 9 Feb 2012 07:56:31 -0500 Message-ID: <4F33C27E.2090304@redhat.com> Date: Thu, 09 Feb 2012 12:56:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: "Gustavo, Luis" CC: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [rfc target-side break conditions 3/5 v2] GDB-side changes References: <4F230A13.9060400@mentor.com> <4F3107C2.2060400@mentor.com> <4F32CDF2.8090906@redhat.com> <4F32E167.6050600@mentor.com> In-Reply-To: <4F32E167.6050600@mentor.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 2012-02/txt/msg00139.txt.bz2 On 02/08/2012 08:56 PM, Luis Gustavo wrote: >> I'm confused. How does this (and all similar places) address the issued I >> pointed out before? If you're passing one to update_global_location_list >> when deleting a breakpoint, you're pretty much defeating the whole >> purpose of the update_global_location_list's argument in the first place. >> > > Updates will only take place when the user explicitly removes/disables a breakpoint. Functions that are deleting breakpoints (like remove_thread_event_breakpoints) won't cause insertion of any breakpoints since they go through the "delete_breakpoint" path, not the delete_breakpoint_with_update one. Ah, got it now. Thanks. But please: > + structures. If UPDATE is true, proceed to update the list of > + locations, otherwise don't update it. */ > > -void > -delete_breakpoint (struct breakpoint *bpt) > +static void > +delete_breakpoint_1 (struct breakpoint *bpt, int update) "update" here is quite confusing, because that's not what is happening. Or at least, update is so overloaded that I'm not understanding it the way you are. The list of locations is still updated/regenerated, and we do delete locations from the target, but, we don't allow new insertions. So, could we s/update/somethingelse/ please? Even pointing at update_global_location_list's description of its parameter would be good. Or maybe, I just had an idea --- I wonder if we made update_global_location_list still re-insert _only_ the _already inserted_ locations when the condition changes, then we'd be good. That is, something like: update_global_location_list: ... - if (breakpoints_always_inserted_mode () && should_insert - && (have_live_inferiors () - || (gdbarch_has_global_breakpoints (target_gdbarch)))) - insert_breakpoint_locations (); + if (breakpoints_always_inserted_mode () + && (have_live_inferiors () + || (gdbarch_has_global_breakpoints (target_gdbarch)))) + { + if (should_insert) + insert_breakpoint_locations (); + else + update_inserted_breakpoint_locations (); + } The problem is that a delete_breakpoint would trigger insertions of all _other_ breakpoints. But if we're allow "reinserting" breakpoints that are _already_ inserted, I think we're fine. > Is disabling breakpoints also something we would like to do without triggering insertions? If so, i'm inclined to go with the same solution as for deleting user breakpoints. Maybe, not sure. Better be safe, I think. It'd be nice to come up with a better way to solve the initial problem that led to update_global_location_list having an argument in the first place. :-/ -- Pedro Alves