Re: MI: "^running" issues

[Nick Roberts <nickrob at snap dot net dot nz>]

 > > I've run Vladimir's example under GDB with my async patch and it also
 > > printed a ^running record and no *stopped, so perhaps ^running should
 > > indeed be printed later.  However, the best way to get the right
 > > asynchronous MI output is probably to develop this code.
 > 
 > Why? It seems to me that outputting "^running" only when the target is
 > running is completely different matter from being able to enter more
 > commands when the target is running. 

I mean more generally than when "^running" is printed, e.g. "next" returning
"^done" instead of "*stopped".

 >                                      I don't see why we can fix "^running"
 > now, so that folks who are either not interested in asynchronous mode, or
 > don't like to wait for it, can get right behaviour now?

If there is a simple fix then it can only make sense.  However, I dont think
this should require removing existing async code.

 >...
 > Assuming that 
 > 
 > 	http://sourceware.org/ml/gdb-patches/2006-11/msg00225.html
 > 	http://thread.gmane.org/gmane.comp.gdb.patches/31081
 > 
 > are the most recent discussions about your patch, it does not seems like
 > "copied verbatim from Apple" is the problem. The problem is that is a big
 > patch,

diffstat (without ChangeLog) gives something like:

 20 files changed, 388 insertions, 25 deletions, 221 modifications

 > and:
 > 
 > 	- I can't find high-level overview of what the patch is trying
 > 	to do, and how it changes gdb behaviour. While a doc patch
 > 	might be premature, some text file would be great.

I've already spent a lot of time on this patch and don't plan to spend much
more when there is no maintainer willing/able to review it.  I'll just keep it
in sync with the repository and maybe look at it more closely again if interest
increases.

 > 	- There are no tests to come with the patch, which makes it
 > 	even harder to understand what are you aiming at.

There's a test attached to msg00225.html listed above.  Also, as I think I've
said before, to run testsuite with the asynchronous event loop just put the
line:

set GDBFLAGS "--async"

at the bottom of site.exp.

at the end of site.exp for the tests.  Asynchronous output from MI requires
new tests but I haven't included these in the diff.

 > That's pretty much what I was complaining recently -- without a design
 > doc for async mode it's not only impossible to understand the existing
 > code, but it's also impossible to understand the code that you're proposing.

I can't write a design doc for code that others have already written.  It
doesn't make it impossible to understand, just more difficult.

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