RE: Re: MI *stopped event with CLI commands

["Marc Khouzam" <marc.khouzam@ericsson.com>]

Volodya,

any opinion on this?
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.  Except for this bug,
I'm not too sure on the advantages of async-mode for DSF-GDB.

So, if you feel this bug can be fixed, I will probably wait
for the fix, instead of risking going to async-mode.

Thanks for your input

Marc



-----Original Message-----
From: Nick Roberts [mailto:nickrob@snap.net.nz]
Sent: Thu 12/18/2008 1:16 AM
To: Marc Khouzam
Cc: Vladimir Prus; gdb@sources.redhat.com
Subject: RE:  Re: MI *stopped event with CLI commands
 
 > > set target-async on
 > > 
 > > first, you do get the full information.  Perhaps this should be the default
 > > for targets which can run asynchronously.
 > 
 > Vladimir Prus wrote:
 > >
 > > Probably. Though it does not change the fact that *stopped without details
 > > sounds like a bug. I'll take a look, though it might take a few days.
 > 
 > I looked into the fact that *stopped worked properly with async on but not
 > with async off (thanks Nick.)  My understanding of GDB internals is quite
 > limited, but I believe what is happening is the following:
 > 
 > When issuing a command that resumes the inferior, say -exec-continue or
 > continue, we eventually end up in method proceed(...) of infrun.c On the
 > call chain to that method, if the command that resumed the inferior was a
 > CLI command (e.g. continue) the uiout structure has been forced to be the
 > CLI uiout; this makes sense to me since we want any output of the CLI
 > command to be formatted as CLI output.  However, once the inferior stops,
 > the output that follows should no longer be in CLI format, I believe.  So,
 > after the inferior is resumed, we should probably go back to the MI uiout.
 >...

I imagine that you can get MI-like output from a CLI execution command by
switching uiout at critical places but asynchronous mode seems to me to
be the natural way to do it as it decouples GDB output from the command
that started the execution, be it MI or CLI.

-- 
Nick                                           http://www.inet.net.nz/~nickrob