From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5144 invoked by alias); 9 Mar 2008 04:55:23 -0000 Received: (qmail 5135 invoked by uid 22791); 9 Mar 2008 04:55:22 -0000 X-Spam-Check-By: sourceware.org Received: from qnxmail.qnx.com (HELO qnxmail.qnx.com) (209.226.137.76) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 09 Mar 2008 04:55:05 +0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.42.96.5]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id XAA32721; Sat, 8 Mar 2008 23:36:50 -0500 Received: from [192.168.20.234] (pptp_vpn-20-234 [192.168.20.234]) by smtp.ott.qnx.com (8.8.8/8.6.12) with ESMTP id XAA21242; Sat, 8 Mar 2008 23:55:02 -0500 Message-ID: <47D36DA5.8050607@qnx.com> Date: Sun, 09 Mar 2008 04:55:00 -0000 From: Aleksandar Ristovski User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Nick Roberts CC: Vladimir Prus , gdb-patches@sources.redhat.com Subject: Re: [patch] fix for PR2424 References: <47CED9FB.7090904@qnx.com> <47D32B57.5020203@qnx.com> <18387.23053.337099.569702@kahikatea.snap.net.nz> In-Reply-To: <18387.23053.337099.569702@kahikatea.snap.net.nz> Content-Type: multipart/mixed; boundary="------------070307000100030306040604" 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: 2008-03/txt/msg00078.txt.bz2 This is a multi-part message in MIME format. --------------070307000100030306040604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1826 Nick Roberts wrote: > > ...(I am not working on CDT but I was explained that > > missing "reason" is to blame, and after the patch I proposed I was told > > things now work as expected). > > As expected for CDT, you mean? I think it can be generalized as "as expected by mi-client". That's my understanding. > > > @Nick: I think the breakpoint should be reported. The fact that it is > > temporary doesn't make it much different than a regular breakpoint... but > > maybe I'm missing something. > > It's only a message so it's probably not that important, but when the user sees: > > Breakpoint 1, main (argc=1, argv=0xbf844314) at myprog.c:95 > > and then looks at the breakpoint list and breakpoint 1 isn't there, he might > get confused. Well... yes... but presumably it was the user who put that breakpoint there in the first place. And on the flip side, the message makes it more clear what really caused inferior to stop. > > Likewise for a frontend with a reason like "breakpoint-hit". Perhaps a new > one, like "temporary-breakpoint-hit", is needed. I agree, the message in both cli and mi case can be more clear. I'm not sure, however, how much headache would this give to existing front-ends. Maybe none since currently in case of temporary breakpoint hit reason is missing altogether. > > >... > > + /* Delete the breakpoint we stopped at, if it wants to be deleted. > > + Delete any breakpoint that is to be deleted at the next stop. */ > > + breakpoint_auto_delete (stop_bpstat); > > annotate_stopped (); > > observer_notify_normal_stop (stop_bpstat); > > } > > If anyone ever uses observer_notify_normal_stop, then presumably > breakpoint_auto_delete would need to go after that. You are most probably right. New diff for infrun.c attached. --------------070307000100030306040604 Content-Type: text/plain; name="PR2424infrun.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="PR2424infrun.c.diff" Content-length: 1012 Index: gdb/infrun.c =================================================================== RCS file: /cvs/src/src/gdb/infrun.c,v retrieving revision 1.266 diff -u -p -r1.266 infrun.c --- gdb/infrun.c 29 Jan 2008 22:47:19 -0000 1.266 +++ gdb/infrun.c 9 Mar 2008 04:48:34 -0000 @@ -3151,11 +3151,6 @@ Further execution is probably impossible } } - /* Delete the breakpoint we stopped at, if it wants to be deleted. - Delete any breakpoint that is to be deleted at the next stop. */ - - breakpoint_auto_delete (stop_bpstat); - /* If an auto-display called a function and that got a signal, delete that auto-display to avoid an infinite recursion. */ @@ -3294,6 +3289,9 @@ Further execution is probably impossible done: annotate_stopped (); observer_notify_normal_stop (stop_bpstat); + /* Delete the breakpoint we stopped at, if it wants to be deleted. + Delete any breakpoint that is to be deleted at the next stop. */ + breakpoint_auto_delete (stop_bpstat); } static int --------------070307000100030306040604--