This is the mail archive of the
mailing list for the GDB project.
Re: MI: "^running" issues
> > 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
> 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
diffstat (without ChangeLog) gives something like:
20 files changed, 388 insertions, 25 deletions, 221 modifications
> - 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
> - 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
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.