MI: asynchronous operation details

MI: asynchronous operation details

[Vladimir Prus]

Hi,
so, in MI mode if I emit "-exec-continue" gdb starts inferiour and
immediately gives me back the prompt, accepting further commands.

However, I can't:
1. Understand what commands can meaningfully be issued while the inferior
is running. Say, all data read/write commands are likely to produce
inconsistent results if inferior is running.
2. Practically figure out which commands can be issued at all. Say, both
-data-evaluate-expression and -exec-continue just hang, returning
nothing. This is with CVS HEAD.

Do I understand correctly that asynchronous MI just don't exist in CVS HEAD,
and only command prompt loop is asynchronous? Even if so, and fully
asynchronous MI is coming, what's the answer to question (1) above?

- Volodya

Re: MI: asynchronous operation details

[Konstantin Karganov]

> so, in MI mode if I emit "-exec-continue" gdb starts inferiour and
> immediately gives me back the prompt, accepting further commands.
Who said it accepts commands? My gdb (6.3) does not.

> However, I can't:
> 1. Understand what commands can meaningfully be issued while the inferior
> is running. Say, all data read/write commands are likely to produce
> inconsistent results if inferior is running.
> 2. Practically figure out which commands can be issued at all. Say, both
> -data-evaluate-expression and -exec-continue just hang, returning
> nothing. This is with CVS HEAD.
>
> Do I understand correctly that asynchronous MI just don't exist in CVS HEAD,
> and only command prompt loop is asynchronous? Even if so, and fully
> asynchronous MI is coming, what's the answer to question (1) above?
Actually, MI also works synchonously. So for 1-2 the answer is "There
are no such commands."
And morover, you cannot issue the command while the inferior is
running. Gdb will process the input only when the execution stops.
As for me, I always ignore "(gdb)" prompt since it means nothing and
made a frontend work  with gdb synchronously (I.e. wait for one answer
before sending another command.).

All this asynchronism in gdb is also a ghost - it looks like it is
real but in fact it do not exist :)

PS. Try to search this mailing list for "(a)synchronous" or smth
alike, you will find the same questions that I asked a year or so ago
:)

--
Best regards,
Konstantin.

Re: MI: asynchronous operation details

[Vladimir Prus]

On Tuesday 22 November 2005 12:07, you wrote:
> > so, in MI mode if I emit "-exec-continue" gdb starts inferiour and
> > immediately gives me back the prompt, accepting further commands.
>
> Who said it accepts commands? My gdb (6.3) does not.

Well, it gives back command prompt. That's what I meant ;-)

> > However, I can't:
> > 1. Understand what commands can meaningfully be issued while the inferior
> > is running. Say, all data read/write commands are likely to produce
> > inconsistent results if inferior is running.
> > 2. Practically figure out which commands can be issued at all. Say, both
> > -data-evaluate-expression and -exec-continue just hang, returning
> > nothing. This is with CVS HEAD.
> >
> > Do I understand correctly that asynchronous MI just don't exist in CVS
> > HEAD, and only command prompt loop is asynchronous? Even if so, and fully
> > asynchronous MI is coming, what's the answer to question (1) above?
>
> Actually, MI also works synchonously. So for 1-2 the answer is "There
> are no such commands."
> And morover, you cannot issue the command while the inferior is
> running. Gdb will process the input only when the execution stops.
> As for me, I always ignore "(gdb)" prompt since it means nothing and
> made a frontend work  with gdb synchronously (I.e. wait for one answer
> before sending another command.).

Hmm.. that's what I do also -- I just wait for the "*stopped" response.

- Volodya

Re: MI: asynchronous operation details

[Bob Rossi]

On Tue, Nov 22, 2005 at 11:30:04AM +0300, Vladimir Prus wrote:
> 
> Hi,
> so, in MI mode if I emit "-exec-continue" gdb starts inferiour and
> immediately gives me back the prompt, accepting further commands.
> 
> However, I can't:
> 1. Understand what commands can meaningfully be issued while the inferior
> is running. Say, all data read/write commands are likely to produce
> inconsistent results if inferior is running.
> 2. Practically figure out which commands can be issued at all. Say, both
> -data-evaluate-expression and -exec-continue just hang, returning
> nothing. This is with CVS HEAD.
> 
> Do I understand correctly that asynchronous MI just don't exist in CVS HEAD,
> and only command prompt loop is asynchronous? Even if so, and fully
> asynchronous MI is coming, what's the answer to question (1) above?

This is a feature that does not currently work. However, it's possible
that Nick Roberts work will address some of this lack of functionality.
If not, I'm sure in the future, either I (you) or someone else will eventually
get this working.

Bob Rossi

Re: MI: asynchronous operation details

[Vladimir Prus]

On Tuesday 22 November 2005 15:12, Bob Rossi wrote:
> On Tue, Nov 22, 2005 at 11:30:04AM +0300, Vladimir Prus wrote:
> > Hi,
> > so, in MI mode if I emit "-exec-continue" gdb starts inferiour and
> > immediately gives me back the prompt, accepting further commands.
> >
> > However, I can't:
> > 1. Understand what commands can meaningfully be issued while the inferior
> > is running. Say, all data read/write commands are likely to produce
> > inconsistent results if inferior is running.
> > 2. Practically figure out which commands can be issued at all. Say, both
> > -data-evaluate-expression and -exec-continue just hang, returning
> > nothing. This is with CVS HEAD.
> >
> > Do I understand correctly that asynchronous MI just don't exist in CVS
> > HEAD, and only command prompt loop is asynchronous? Even if so, and fully
> > asynchronous MI is coming, what's the answer to question (1) above?
>
> This is a feature that does not currently work. However, it's possible
> that Nick Roberts work will address some of this lack of functionality.
> If not, I'm sure in the future, either I (you) or someone else will
> eventually get this working.

Ok, but -- why do I ever want to issue commands while inferior is running? For 
which kind of commands is that useful?

- Volodya

Re: MI: asynchronous operation details

[Bob Rossi]

On Tue, Nov 22, 2005 at 03:20:23PM +0300, Vladimir Prus wrote:
> On Tuesday 22 November 2005 15:12, Bob Rossi wrote:
> > On Tue, Nov 22, 2005 at 11:30:04AM +0300, Vladimir Prus wrote:
> > > Hi,
> > > so, in MI mode if I emit "-exec-continue" gdb starts inferiour and
> > > immediately gives me back the prompt, accepting further commands.
> > >
> > > However, I can't:
> > > 1. Understand what commands can meaningfully be issued while the inferior
> > > is running. Say, all data read/write commands are likely to produce
> > > inconsistent results if inferior is running.
> > > 2. Practically figure out which commands can be issued at all. Say, both
> > > -data-evaluate-expression and -exec-continue just hang, returning
> > > nothing. This is with CVS HEAD.
> > >
> > > Do I understand correctly that asynchronous MI just don't exist in CVS
> > > HEAD, and only command prompt loop is asynchronous? Even if so, and fully
> > > asynchronous MI is coming, what's the answer to question (1) above?
> >
> > This is a feature that does not currently work. However, it's possible
> > that Nick Roberts work will address some of this lack of functionality.
> > If not, I'm sure in the future, either I (you) or someone else will
> > eventually get this working.
> 
> Ok, but -- why do I ever want to issue commands while inferior is running? For 
> which kind of commands is that useful?

You could interupt the inferior, to tell it to stop. I think that would
be equivalent to typing ^c at the console now. Also, you could ask 
GDB if it is currently busy, to determine if you can send another
command. That way, you wouldn't have to keep track of the state of GDB,
you could just always ask it what it's state is.

I'm sure there are other useful features also. However, I agree, it
doesn't seem to be necessary. It's just better.

Bob Rossi

Re: MI: asynchronous operation details

[Vladimir Prus]

On Tuesday 22 November 2005 16:38, Bob Rossi wrote:

> > > This is a feature that does not currently work. However, it's possible
> > > that Nick Roberts work will address some of this lack of functionality.
> > > If not, I'm sure in the future, either I (you) or someone else will
> > > eventually get this working.
> >
> > Ok, but -- why do I ever want to issue commands while inferior is
> > running? For which kind of commands is that useful?
>
> You could interupt the inferior, to tell it to stop. I think that would
> be equivalent to typing ^c at the console now. 

Well, exactly. I can do "^C" today, so nothing gained at all.

> Also, you could ask 
> GDB if it is currently busy, to determine if you can send another
> command. That way, you wouldn't have to keep track of the state of GDB,
> you could just always ask it what it's state is.

That would be handy, but if there's "^running" packet in *all* cases where 
inferiour start running (e.g. when "run" is hidden inside user-defined 
command), then keeping track of state of GDB means just a single bool 
variable -- not much. And it GUI, you need to keep track of the state anyway,
so that you can grey out some buttons.

> I'm sure there are other useful features also. 

Still curious what are they ;-)

- Volodya

Re: MI: asynchronous operation details

[Bob Rossi]

On Tue, Nov 22, 2005 at 04:49:22PM +0300, Vladimir Prus wrote:
> On Tuesday 22 November 2005 16:38, Bob Rossi wrote:
> 
> > > > This is a feature that does not currently work. However, it's possible
> > > > that Nick Roberts work will address some of this lack of functionality.
> > > > If not, I'm sure in the future, either I (you) or someone else will
> > > > eventually get this working.
> > >
> > > Ok, but -- why do I ever want to issue commands while inferior is
> > > running? For which kind of commands is that useful?
> >
> > You could interupt the inferior, to tell it to stop. I think that would
> > be equivalent to typing ^c at the console now. 
> 
> Well, exactly. I can do "^C" today, so nothing gained at all.

Well, clearly sending the ^C is not as nice as the MI -exec-interrupt
command. The former is simply legacy from a console driven front end.
It's not intuitive.

> > I'm sure there are other useful features also. 
> 
> Still curious what are they ;-)

If you look in the documentation, the 'Asynchronous command.' will be
next to each command that is supposed to support an asynchronous style
command. For example:

    -exec-interrupt

    Asynchronous command. Interrupts the background execution of the
    target. 
    ...

Bob Rossi

Re: MI: asynchronous operation details

[Vladimir Prus]

On Tuesday 22 November 2005 17:00, Bob Rossi wrote:

> > > You could interupt the inferior, to tell it to stop. I think that would
> > > be equivalent to typing ^c at the console now.
> >
> > Well, exactly. I can do "^C" today, so nothing gained at all.
>
> Well, clearly sending the ^C is not as nice as the MI -exec-interrupt
> command. The former is simply legacy from a console driven front end.
> It's not intuitive.

Yes, just a bit.

> > > I'm sure there are other useful features also.
> >
> > Still curious what are they ;-)
>
> If you look in the documentation, the 'Asynchronous command.' will be
> next to each command that is supposed to support an asynchronous style
> command. For example:
>
>     -exec-interrupt

Except for "interrupt", other occurences are for various flavours of "run" -- 
continue/next/nexti/step/stepi/unti/finish. So, it still looks like 
"-exec-interrupt" is the only command that can be meaningfully issued while 
inferior is running.

- Volodya

Re: MI: asynchronous operation details

[Daniel Jacobowitz]

On Tue, Nov 22, 2005 at 05:11:58PM +0300, Vladimir Prus wrote:
> Except for "interrupt", other occurences are for various flavours of "run" -- 
> continue/next/nexti/step/stepi/unti/finish. So, it still looks like 
> "-exec-interrupt" is the only command that can be meaningfully issued while 
> inferior is running.

Not a lot of work has been done on taking advantage of asynchronous
execution, since so few targets offer it today.  There's going to be
more in the future, I think.  It's important mostly as an
infrastructure change for the GDB internals.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

How can I unsubscribe?

[Gengis Toledo]

Thanks

- - - - - - - - - - - - - - - - - - - - - - - - 
       Correo enviado con Software libre
   http://es.wikipedia.org/wiki/Software_libre
- - - - - - - - - - - - - - - - - - - - - - - -

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: How can I unsubscribe?

[Daniel Jacobowitz]

The headers of every message from the list contain unsubcribe
instructions.  Also see http://sourceware.org/ml/#faqs.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: How can I unsubscribe?

[Daniel Jacobowitz]

The headers of every message from the list contain unsubcribe
instructions.  Also see http://sourceware.org/ml/#faqs.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: How can I unsubscribe?

[Christopher Faylor]

On Tue, Nov 22, 2005 at 10:02:13AM -0500, Daniel Jacobowitz wrote:
>The headers of every message from the list contain unsubcribe
>instructions.  Also see http://sourceware.org/ml/#faqs.

I can add a trailer to all mail to this mailing list which has this
information, too, if needed.

The cygwin list has this for a trailer:

  --
  Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
  Problem reports:       http://cygwin.com/problems.html
  Documentation:         http://cygwin.com/docs.html
  FAQ:                   http://cygwin.com/faq/

Is there any interest in adding this kind of info to the gdb list(s)?

cgf

RE: How can I unsubscribe?

[Dave Korn]

Christopher Faylor wrote:
> On Tue, Nov 22, 2005 at 10:02:13AM -0500, Daniel Jacobowitz wrote:
>> The headers of every message from the list contain unsubcribe
>> instructions.  Also see http://sourceware.org/ml/#faqs.
> 
> I can add a trailer to all mail to this mailing list which has this
> information, too, if needed.
> 
> The cygwin list has this for a trailer:
> 
>   --
>   Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>   Problem reports:       http://cygwin.com/problems.html
>   Documentation:         http://cygwin.com/docs.html
>   FAQ:                   http://cygwin.com/faq/
> 
> Is there any interest in adding this kind of info to the gdb list(s)?
> 
> cgf


  Please!  I reckon all the sourceware lists could use a footer with a pointer
to the mailing list faq, and perhaps also the project's homepage and the
list's archive.... 



    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: MI: asynchronous operation details

[Eli Zaretskii]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Tue, 22 Nov 2005 15:20:23 +0300
> 
> why do I ever want to issue commands while inferior is running? For 
> which kind of commands is that useful?

It would be useful for commands that do not access the running
inferior.  Simple examples include `help' commands.  Less trivial
examples include commands that consult the symbol tables.  Really
tricky commands would be useful if and when GDB supports debugging
more than one program--you could examine data in one program while the
other one runs.

But, as Daniel points out, for now this is just an infrastructure that
still awaits to be used.

Re: MI: asynchronous operation details

[Nick Roberts]

 > continue/next/nexti/step/stepi/unti/finish. So, it still looks like 
 > "-exec-interrupt" is the only command that can be meaningfully issued while 
 > inferior is running.

Rather than discuss the possible benefits of asynchronous operation in an
abstract manner, I suggest that you integrate as much of MI into your
front-end (kdevelop?) to find out the limitations.  These limitations
can then be discussed within a context.

In Emacs, Richard Stallman has stated that any front-end fro GDB must keep the
GUD buffer.  This is used to enter CLI commands.  I have found that the best
way to get CLI commands to work well with MI is through asynchronous
operation.  Apple have already done this with their version of GDB and you can
see it in action by installing a copy of Opendarwin.

I believe that Daniel J is interested in asynchronous operation for scripting,
but until you see a need for it for your purposes, I see little point in
debating its merits or lack of them.

Nick

Re: MI: asynchronous operation details

[Nick Roberts]

[in future, please cc the list]

 > > Rather than discuss the possible benefits of asynchronous operation in an
 > > abstract manner, I suggest that you integrate as much of MI into your
 > > front-end (kdevelop?) to find out the limitations.  These limitations
 > > can then be discussed within a context.
 > 
 > So, this amount to saying "you need to convert all of KDevelop to MI to 
 > understand how anynchronous operation is good"?

I'm saying that if you only look for perceived flaws in MI and are not
prepared to write any code that uses it, then you're wasting other people's
time.

 >                                                Sorry, I'm not happy with 
 > this idea -- if "anynchronous operation" is one of selling points of MI, and 
 > there's no clear list of advantages of anynchronous operation, I'm rather 
 > worried.

AFAIK no-one is selling anything.  Currently anynchronous operation is not
really even part of MI.  If you choose to use MI and contribute to its
development, that is welcome.  If you decide not to use it, thats your choice.

 > Speaking about limitations -- KDevelop already has a debugger, writted before 
 > me, and it works mostly fine. There are no grave limitations I want to fix. 
 > The reasons I'm trying MI are just:
 > 
 >    - Simplify parsing of responses.
 >    - Easily determine if command has failed or not.
 > 
 > > In Emacs, Richard Stallman has stated that any front-end fro GDB must keep
 > > the GUD buffer.  This is used to enter CLI commands.  I have found that the
 > > best way to get CLI commands to work well with MI is through asynchronous
 > > operation.  
 > 
 > Why?

It decouples the input, CLI or MI, from the output.  There might be other ways
and it might be partly fortuitous, because all the MI commands that control
execution: -exec-run, -exec-next, -exec-finish etc, are really CLI commands in
disguise, but it works.  Also, thats the path taken by Apple who have a lot of
experience in this area with Project Builder and Xcode.  Thats enough to
convince me.

 > ...Large number of commands are meaningless while inferiour is running -- no 
 > matter if those commands are CLI ones.
 > Look, I'm not trying to say asynchronous operation is useless, or something. 
 > I'm trying to understand if I'll be missing something by ignoring it, and if 
 > I should design to use asynchronous operation. 
 >
 > > Apple have already done this with their version of GDB and you 
 > > can see it in action by installing a copy of Opendarwin.
 > 
 > To begin with, I don't have OSX anywhere to try Opendarwin.

You don't need OSX.  You can download Opendarwin from:

http://www.opendarwin.org

and install it on a partition.  The version that I have (OpenDarwin 7.2.1) is
all comand line and came on a CD.