From: Aleksandar Ristovski <aristovski@qnx.com>
To: Nick Roberts <nickrob@snap.net.nz>
Cc: Vladimir Prus <ghost@cs.msu.su>, gdb-patches@sources.redhat.com
Subject: Re: [patch] fix for PR2424
Date: Sun, 09 Mar 2008 04:55:00 -0000 [thread overview]
Message-ID: <47D36DA5.8050607@qnx.com> (raw)
In-Reply-To: <18387.23053.337099.569702@kahikatea.snap.net.nz>
[-- Attachment #1: Type: text/plain, Size: 1826 bytes --]
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.
[-- Attachment #2: PR2424infrun.c.diff --]
[-- Type: text/plain, Size: 1012 bytes --]
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
next prev parent reply other threads:[~2008-03-09 4:55 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-05 17:36 Aleksandar Ristovski
2008-03-08 11:31 ` Nick Roberts
2008-03-08 18:36 ` Vladimir Prus
2008-03-09 0:12 ` Aleksandar Ristovski
2008-03-09 3:32 ` Nick Roberts
2008-03-09 4:55 ` Aleksandar Ristovski [this message]
2008-03-10 8:11 ` Vladimir Prus
2008-03-10 14:29 ` Aleksandar Ristovski
2008-03-10 14:45 ` Vladimir Prus
2008-03-10 17:18 ` Aleksandar Ristovski
2008-03-10 17:36 ` Vladimir Prus
2008-03-10 18:50 ` Aleksandar Ristovski
2008-04-01 19:41 Aleksandar Ristovski
2008-04-14 15:16 Aleksandar Ristovski
2008-04-14 18:06 ` Daniel Jacobowitz
2008-04-15 15:07 Aleksandar Ristovski
2008-04-15 15:25 ` Daniel Jacobowitz
2008-04-16 13:17 ` Vladimir Prus
2008-04-23 11:16 ` Vladimir Prus
2008-04-15 15:31 Aleksandar Ristovski
2008-04-16 18:28 Aleksandar Ristovski
2008-04-23 17:48 Aleksandar Ristovski
2008-04-23 17:49 ` Vladimir Prus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47D36DA5.8050607@qnx.com \
--to=aristovski@qnx.com \
--cc=gdb-patches@sources.redhat.com \
--cc=ghost@cs.msu.su \
--cc=nickrob@snap.net.nz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox