MI *stopped event with CLI commands

MI *stopped event with CLI commands

[Marc Khouzam]

Hi,

with the latest MI changes, when running in MI mode, a *stopped event is issued whenever
the inferior stops, even if the last command was a CLI command.
However, the stopped event is bare if the command is a CLI command.

*stopped
instead of
*stopped,reason="breakpoint-hit",disp="keep",bkptno="1",thread-id="1",
stopped-threads="all",frame={addr="0x08048415",func="main",args=[],file="c.cc",fullname="c.cc",line="5"}

Was this intended?  And if so, what should a frontend do in this case?  
We can parse the CLI output or send MI commands to get the info...
However, it seems to me that having to do that, defeats the purpose of having 
the *stopped event after CLI commands.

Wouldn't be nice if the stopped event always had the full information?

Thanks

Marc

Re: MI *stopped event with CLI commands

[Nick Roberts]

 > with the latest MI changes, when running in MI mode, a *stopped event is issued whenever
 > the inferior stops, even if the last command was a CLI command.
 > However, the stopped event is bare if the command is a CLI command.
 > 
 > *stopped
 > instead of
 > *stopped,reason="breakpoint-hit",disp="keep",bkptno="1",thread-id="1",
 > stopped-threads="all",frame={addr="0x08048415",func="main",args=[],file="c.cc",fullname="c.cc",line="5"}
 > 
 > Was this intended?  And if so, what should a frontend do in this case?  
 > We can parse the CLI output or send MI commands to get the info...
 > However, it seems to me that having to do that, defeats the purpose of having 
 > the *stopped event after CLI commands.
 > 
 > Wouldn't be nice if the stopped event always had the full information?

If you do:

set target-async on

first, you do get the full information.  Perhaps this should be the default
for targets which can run asynchronously.

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

Re: MI *stopped event with CLI commands

[Vladimir Prus]

Nick Roberts wrote:

>  > with the latest MI changes, when running in MI mode, a *stopped event is issued whenever
>  > the inferior stops, even if the last command was a CLI command.
>  > However, the stopped event is bare if the command is a CLI command.
>  > 
>  > *stopped
>  > instead of
>  > *stopped,reason="breakpoint-hit",disp="keep",bkptno="1",thread-id="1",
>  >
stopped-threads="all",frame={addr="0x08048415",func="main",args=[],file="c.cc",fullname="c.cc",line="5"}
>  > 
>  > Was this intended?  And if so, what should a frontend do in this case?
>  > We can parse the CLI output or send MI commands to get the info...
>  > However, it seems to me that having to do that, defeats the purpose of having
>  > the *stopped event after CLI commands.
>  > 
>  > Wouldn't be nice if the stopped event always had the full information?
> 
> If you do:
> 
> set target-async on
> 
> first, you do get the full information.  Perhaps this should be the default
> for targets which can run asynchronously.

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.

- Volodya

RE: Re: MI *stopped event with CLI commands

[Marc Khouzam]

Nick Roberts wrote:
> 
> 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.

In async mode, this does happens because proceed(...) returns immediately and everything
gets undone nicely.  But when async is off proceed(...) blocks with the code:
  if (!target_can_async_p ())
    {
      wait_for_inferior (0);
      normal_stop ();
    }

Since normal_stop() is called directly from proceed(...) the uiout is still set to CLI 
in this case, and the information of the *stopped event is created in a CLI format, which 
explains why *stopped has no information.

So, if I understood all this right, I think the uiout should be reset before calling
normal_stop().  I'm sure this is an over-simplification, but I hope it can point
in the right direction for this bug.

Thanks

Marc

RE: Re: MI *stopped event with CLI commands

[Nick Roberts]

 > > 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

RE: Re: MI *stopped event with CLI commands

[Marc Khouzam]

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

RE: Re: MI *stopped event with CLI commands

[Nick Roberts]

 > 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.

Also very few targets currently support async mode.  Linux, remote, Dicos?

 >                                       Except for this bug,
 > I'm not too sure on the advantages of async-mode for DSF-GDB.

Non-stop mode seems to require async-mode but I'm not sure why it doesn't
enable it automatically.

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

It's not really a bug because CLI execution commands have never generated full
MI output in synchronous mode.  I think synchronous really means that control
stays with the interpreter that issues the execution command until *after*
execution has finished.  So any MI output, in this case, is really faked
output.

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