This is the mail archive of the
mailing list for the GDB project.
RE: Re: MI *stopped event with CLI commands
- From: Nick Roberts <nickrob at snap dot net dot nz>
- To: "Marc Khouzam" <marc dot khouzam at ericsson dot com>
- Cc: "Vladimir Prus" <vladimir at codesourcery dot com>, <gdb at sources dot redhat dot com>
- Date: Tue, 13 Jan 2009 00:35:15 +1300
- Subject: RE: Re: MI *stopped event with CLI commands
- References: <6D19CA8D71C89C43A057926FE0D4ADAA04E1BEC8@ecamlmw720.eamcs.ericsson.se> <email@example.com> <firstname.lastname@example.org> <6D19CA8D71C89C43A057926FE0D4ADAA04E1BED4@ecamlmw720.eamcs.ericsson.se> <email@example.com> <6D19CA8D71C89C43A057926FE0D4ADAA04E1BEED@ecamlmw720.eamcs.ericsson.se>
> I could switch to async mode to solve this problem, but
> I'm hesitant to do so because it may have side-effects to
> DSF-GDB that I may not be aware of.
Also very few targets currently support async mode. Linux, remote, Dicos?
> Except for this bug,
> I'm not too sure on the advantages of async-mode for DSF-GDB.
Non-stop mode seems to require async-mode but I'm not sure why it doesn't
enable it automatically.
> So, if you feel this bug can be fixed, I will probably wait
> for the fix, instead of risking going to async-mode.
It's not really a bug because CLI execution commands have never generated full
MI output in synchronous mode. I think synchronous really means that control
stays with the interpreter that issues the execution command until *after*
execution has finished. So any MI output, in this case, is really faked