Re: MI: "^running" issues

[Vladimir Prus <ghost at cs dot msu dot su>]

Nick Roberts wrote:

>  > > I can't reproduce this.  It looks like partial recipe.
>  > 
>  > I suppose I can try to make a full recipe -- but only if you're
>  > intending to fix that ;-)
> 
> I can't offer to fix something that I can't even reproduce.  But in any
> case you appear to be proposing to `fix' it by moving "^running" to
> target_resume. I think we need to establish that the bug is real first.

I compile the attached file with

        gcc -o watch -g watch.c

and then build FSF HEAD of gdb and run it like

        gdb -nx --i=mi watch

and then I get the attached session. This is a Core Duo machine.
Note that the session has two -exec-step.  I don't know why it's so --
the version I've tried this before would emit the error right away.
But the error and the problem, is still the same.

>  > > I'm working in the opposite direction: trying to get GDB to work
>  > > asynchronously.  I don't see the point of ripping out what is already
>  > > there.
>  > 
>  > Then, can you please provide a specification of what "asynchronously"
>  > means, and why it's good for users and frontends?
> 
> To me, it means that GDB can process user input even when the program
> being
> debugged is executing.  Apple use it in Xcode.  It means the frontend can
> interrogate GDB at any time.  

As I already said to Eli, is there any list of commands that can be meaningfully
used while the target is running?

> Also CLI commands give MI async output as 
> mentioned previously.

It looks to me a completely independent thing.

- Volodya

Attachment: log
Description: Text document

int a;
int b;
int c;
int d;
int e;

int x, y;

int main()
{
    x = 1;
    x = 2;
    return 0;
}