Re: mi/671: Changing GDB/MI spec say the should be a termination "(gdb)\n" string

Re: mi/671: Changing GDB/MI spec say the should be a termination "(gdb)\n" string

[drow]

Synopsis: Changing GDB/MI spec say the should be a termination "(gdb)\n" string

State-Changed-From-To: open->closed
State-Changed-By: drow
State-Changed-When: Sun Apr 20 15:31:14 2008
State-Changed-Why:
    I stumbled on this old bug... I don't think it's useful to keep open any more, but feel free to reopen if you like.  Nick, Vlad, Pedro, et al have been working on truly async GDB/MI and are making great progress.

http://sourceware.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=671

Re: mi/671: Changing GDB/MI spec say the should be a termination "(gdb)\n" string

[Andrew Cagney]

The following reply was made to PR mi/671; it has been noted by GNATS.

From: Andrew Cagney <ac131313@redhat.com>
To: gdb-gnats@sources.redhat.com
Cc:  
Subject: Re: mi/671: Changing GDB/MI spec say the should be a termination
 "(gdb)\n" string
Date: Fri, 11 Apr 2003 11:36:51 -0400

 > 1:int main() {
 > 2:      int x;
 > 3:      pthread_create(NULL, NULL, routine, NULL);
 > 4:      printf("Hello world\n");
 > 5:      sleep(200000); // Or a very time consuming function called.
 > 6:      printf("After the long wait\n");
 > 7:      return 0;
 > 8:}
 > 
 > gdb/mi will issue things like:
 > (gdb)
 > -break-insert file.c:6
 > ^done,bkpt={...}
 
 There should be a:
 
 	(gdb)
 
 termination here.
 
 > ~"[New Thread 1024 (LWP 30497)]\n"
 > ~"[Switching to Thread 1024 (LWP 30497)]\n"
 
 And here.
 
 > .... wait for the sleep ....
 > *stopped,reason=...
 > (gdb)
 > 
 
 The target being used probably isn't async.  Have you tried it with 
 `target remote-async'?
 
 Andrew
 
 
 > You do not have the "(gdb)" comming right away.
 > 
 >         OUTPUT ==> (OUT-OF-BAND-RECORD)* [RESULT-RECORD] "(gdb)"nl
 > 
 > I read the definition like you can accumulate outputs and deal with them only
 > when encounter "(gdb)"  which is true unless you want to wait for the sleep() to
 > finish.  In practice we can consider Out-of-band completely async and should be
 > process right away.  It was not clear at first sight, IMHO.