Re: [patch] fix for PR2424

[Vladimir Prus <vladimir at codesourcery dot com>]

On Sunday 09 March 2008 03:12:07 you wrote:
> Vladimir Prus wrote:
> > FWIW, you don't say what function in mi-support.exp is changed,
> > and it would be better if your patch was generated with -u (unified diff,
> > 3 lines of context) -- the current one has no context at all, so I
> > can only guess which function that is.
> 
> Please find attached new diffs.
> 
> 
> > 
> > Speaking of the problem itself -- in PR2424 you say:
> > 
> >         When inferior stops at temporary breakpoint, message is:
> >         *stopped,thread-id="0",.......
> >         without mentioning "reason=breakpoint-hit"
> >         This causes issues for multithreaded programs.
> > 
> > What issues does it cause for MT programs?
> 
> When inferior hits a temporary breakpoint, due to breakpoint removal the reason 
> for stop is "lost in translation". This leaves user guessing what the reason for 
> stop was. This  is applicable to both single and multi threaded inferiors, but 
> gets more annoying when multiple threads exist since then client program (in my 
> case IDE - CDT) can not figure out which thread caused the stop 

The GDB output you have provided above actually includes thread id, so what problem
does CDT have with figuring thread? In fact, CDT4's RxThread.java has the following:

		// We were stopped for some unknown reason, for example
		// GDB for temporary breakpoints will not send the
		// "reason" ??? still fire a stopped event.
		if (list.isEmpty()) {
			if (session.getMIInferior().isRunning()) {
				session.getMIInferior().setSuspended();
				MIEvent event = new MIStoppedEvent(session, rr);
				session.fireEvent(event);
			}
		}

> in addition to  
> not knowing the reason (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).

So, could it be a CDT issue, after all?

> @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.

Independent of actually CDT issue, I still think accurately reporting stop reason
would be good. Can we probably look at breakpoints 'disp' field and either
print "Breakpoint" or "Temporary breakpoint", and likewise either "breakpoint-hit" or
"temporary-breakpoint-hit", in breakpoint.c:print_it_typical?

- Volodya