From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1784 invoked by alias); 7 Feb 2012 22:08:27 -0000 Received: (qmail 1775 invoked by uid 22791); 7 Feb 2012 22:08:25 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from elasmtp-spurfowl.atl.sa.earthlink.net (HELO elasmtp-spurfowl.atl.sa.earthlink.net) (209.86.89.66) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 07 Feb 2012 22:08:11 +0000 Received: from [70.170.59.51] (helo=macbook2.local) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RutCs-00053r-3u for gdb-patches@sourceware.org; Tue, 07 Feb 2012 17:08:10 -0500 Message-ID: <4F31A0C9.9080004@earthlink.net> Date: Tue, 07 Feb 2012 22:08:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: [rfc target-side break conditions 3/5 v2] GDB-side changes References: <4F230A13.9060400@mentor.com> In-Reply-To: <4F230A13.9060400@mentor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da94049059f14aebd7ea37e92ae244a60f297350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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: 2012-02/txt/msg00091.txt.bz2 On 1/27/12 12:33 PM, Luis Gustavo wrote: > A few more changes on this patch. It addresses all the previous > comments and suggestions. > > > I've changed the "info break" output a little. We now display " > evaluates conditions" next to the location description, and we also > output that same information via MI. Though it works, i'm not entirely > happy with the way it is displayed. > > Previously i displayed such information next to the condition field, > but it doesn't work right for breakpoints with multiple locations > since the conditions are printed for the breakpoint instead of the > locations. Suggestions? Can it actually happen that some locations of a breakpoint are evaluated host-side, and other target-side? It makes my head hurt trying to think of an example. :-) In any case, the note should follow the condition, and I suggest the wording "(host evals)" and "(target evals)" if all locations are going to be handled the same way. If locations are varying, then the condition follower can say "(host or target evals)" then each location description can say just "(host)" or "(target)". It's a little messier to calculate, but users will appreciate the clarity. (I'm preferring "host" to "gdb", but I suppose that might be confusing if GDB was talking to a sprite also running on the host and controlling target via JTAG.) +/* Mark locations as "conditions have changed" in case + the target supports evaluating conditions on + its side. */ This is kind of petty, but shouldn't the lines be filled? I think Emacs would make this a two-line comment. + warning (_("Target does not support condition evaluation.\n" + "Using GDB evaluation mode instead.")); I tend to think this should say "breakpoint condition", so it's clear that it's not referring to tracepoint conditions, or command list conditions, or Python conditions, etc. + /* If we got here, it means the condition could not be parse to a valid be parsed (Eventually we should be nicer and say *why* the condition didn't make the cut. Users would be happy to replace a convenience var with a literal value if they knew that's all that was wrong.) - update_global_location_list (0); + if (is_breakpoint (bpt)) + update_global_location_list (1); + else + update_global_location_list (0); update_global_location_list (is_breakpoint (bpt)) Stan