MI: is target running

MI: is target running

[Vladimir Prus]

Hi,
I have a simple question -- how a GUI frontend can determine if gdb is
running the target at the moment? It's obviously necessary to disable some
actions, enable some other actions and so on.

Say, I'm using MI. However, user might have a lot of gdb macros he wants to
still use, and those macros can contain "run", or "continue" commands --
why not.

Here's what I've tried:

        ghost@zigzag:/tmp$ cat a.gdb
        define myrun
        run
        end
        ghost@zigzag:/tmp$ gdb --i=mi a.out
        ~"GNU gdb 6.3-debian\n"
        (gdb)
        source a.gdb
        &"source a.gdb\n"
        ^done
        (gdb)
        interpreter console "myrun"
        &"interpreter console \"myrun\"\n"
        Hi
        
        Program exited normally.
        ^done
        (gdb)

So, for "run" command embedded in gdb macro invoked via "interpreter
console", there's no "^running" in the output. So, GUI can't detect that
the target is running.

Is this a defect? Should not "^running" be emitted in all cases when target
starts running?

- Volodya

MI: is target running

[Nick Roberts]

 > So, for "run" command embedded in gdb macro invoked via "interpreter
 > console", there's no "^running" in the output. So, GUI can't detect that
 > the target is running.

[Generally myrun is referred a "user-defined command"]

I don't quite understand your example as this is also true if you just do:

interpreter console run

i.e. it is a consequence of using CLI within MI and not just one of invoking
a user-defined command.

 > Is this a defect? Should not "^running" be emitted in all cases when target
 > starts running?

Yes, I think it should.  I have made changes to GDB, based on Apple's work,
that makes GDB run asynchronously.  This means that the state of the inferior
is reported regardless of whether the command executed was from MI or CLI.

After the release, I will make a branch for these changes and hope that they
can be merged in to mainline for the release after.  I will welcome any help
with that effort.

Nick

Re: MI: is target running

[Vladimir Prus]

On Friday 18 November 2005 16:37, you wrote:
>  > So, for "run" command embedded in gdb macro invoked via "interpreter
>  > console", there's no "^running" in the output. So, GUI can't detect that
>  > the target is running.
>
> [Generally myrun is referred a "user-defined command"]
>
> I don't quite understand your example as this is also true if you just do:
>
> interpreter console run
>
> i.e. it is a consequence of using CLI within MI and not just one of
> invoking a user-defined command.

Yes, but for plain old run I can just compare command being run with "run" 
literal. For user-defined-command, it's simply not possible.

>  > Is this a defect? Should not "^running" be emitted in all cases when
>  > target starts running?
>
> Yes, I think it should.  I have made changes to GDB, based on Apple's work,
> that makes GDB run asynchronously.  This means that the state of the
> inferior is reported regardless of whether the command executed was from MI
> or CLI.

Cool. But what does "asynchronously" means, exactly? 

> After the release, I will make a branch for these changes and hope that
> they can be merged in to mainline for the release after.  I will welcome
> any help with that effort.

I hope to check that branch out.

- Volodya

Re: MI: is target running

[Nick Roberts]

 > > Yes, I think it should.  I have made changes to GDB, based on Apple's work,
 > > that makes GDB run asynchronously.  This means that the state of the
 > > inferior is reported regardless of whether the command executed was from MI
 > > or CLI.
 > 
 > Cool. But what does "asynchronously" means, exactly? 

I'm not the expert, but I can tell you what I understand by it.  Basically GDB
can accept further input even while the inferior is running.  I guess that the
output of some commands will depend on the timing, but others won't - I'm not
sure of the full implications.

In terms of the code, target_can_async_p () is true and with MI, for example,
GDB picks up mi_exec_async_cli_cmd_continuation to print the *stopped record,
even with CLI commands like "run".  But its probably better to let the code
speak for itself when the branch is created.

By giving each MI command a token number, it can be paired up with its output.
There's no need to have the concept of a queue, and so I think the front-end
is less likely to get confused.

As far as I know, asynchronous operation fits in with the general aims of the
GDB community, but it is certainly not something that I can implement on my
own.  So I can't say for sure that it will happen, but just that I would like
it to happen.

Nick