This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] Broken -thread-info output in non-stop mode.
- From: Pedro Alves <pedro at codesourcery dot com>
- To: Vladimir Prus <vladimir at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org, Marc Khouzam <marc dot khouzam at ericsson dot com>, laszlo dot benedek at ericsson dot com
- Date: Tue, 17 Mar 2009 05:30:19 +0000
- Subject: Re: [RFC] Broken -thread-info output in non-stop mode.
- References: <200903151825.14242.pedro@codesourcery.com> <200903161249.19207.vladimir@codesourcery.com>
On Monday 16 March 2009 09:49:18, Vladimir Prus wrote:
> On Sunday 15 March 2009 21:25:13 Pedro Alves wrote:
> Ouch. But wait, how is 'resume' is done? My impression was that all
> resumptions of the as direct result on user commands are done via
> 'proceed'. Looking at CVS HEAD, I see one use of proceed in
> proceed_after_attach_callback that I cannot immediately correlate with
> a user command, but all others are clearly correlated. So, maybe MI
> should output ^running only when proceed is called?
You're pretty much right. If we need to carry the target a bit,
we'll only proceed it in a continuation, or call target_resume
directly.
> Well, they did not output ^running for 10 years, but it does not mean
> it was bad. KDevelop users did complain that issuing CLI commands resulted
> in no feedback that the application is actually running. We can suppress
> this in async mode, but then the solution starts to include so many
> assumptions that it makes me nervous ;-)
I take it you'll make KDevelop handle ^done + *running at some
point. :-)
> Let me know what you think about
> the proceed idea.
I like it, thanks! I'm about to post a mini patch series
implementing it. In the process I cleaned up a few things that
were sort of in the way.
--
Pedro Alves