Fix MI/async testsuite

Fix MI/async testsuite

[Vladimir Prus]

[-- Attachment #1: Type: text/plain, Size: 345 bytes --]


My previous patches to add =thread-created have broken MI testsuite
in async mode, since in async mode, the order of output is somewhat
different and the output for -exec-run is:

  ^running
  =thread-created
  (gdb)

with =thread-creating going before prompt, while in sync mode 
(gdb) follows ^running immediately.

Fixed thusly.

- Volodya


[-- Attachment #2: commit.diff --]
[-- Type: text/x-diff, Size: 1119 bytes --]

Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/ChangeLog,v
retrieving revision 1.1630
diff -u -p -r1.1630 ChangeLog
--- ChangeLog	4 May 2008 04:04:10 -0000	1.1630
+++ ChangeLog	4 May 2008 12:13:45 -0000
@@ -1,3 +1,8 @@
+2008-05-04  Vladimir Prus  <vladimir@codesourcery.com>
+
+	* lib/mi-support.exp (mi_run_cmd): Allow for =thread-created
+	notification to appear.
+	
 2008-05-04  Daniel Jacobowitz  <dan@debian.org>
 
 	* gdb.base/fullname.c: New file.
Index: lib/mi-support.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/lib/mi-support.exp,v
retrieving revision 1.59
diff -u -p -r1.59 mi-support.exp
--- lib/mi-support.exp	30 Apr 2008 18:25:53 -0000	1.59
+++ lib/mi-support.exp	4 May 2008 12:13:45 -0000
@@ -821,7 +821,7 @@ proc mi_run_cmd {args} {
 
     send_gdb "220-exec-run $args\n"
     gdb_expect {
-	-re "220\\^running\r\n${mi_gdb_prompt}" {
+	-re "220\\^running\r\n(=thread-created,id=\"1\"\r\n)?${mi_gdb_prompt}" {
 	}
 	timeout {
 	    perror "Unable to start target"

Re: Fix MI/async testsuite

[Daniel Jacobowitz]

On Sun, May 04, 2008 at 04:18:14PM +0400, Vladimir Prus wrote:
> 
> My previous patches to add =thread-created have broken MI testsuite
> in async mode, since in async mode, the order of output is somewhat
> different and the output for -exec-run is:
> 
>   ^running
>   =thread-created
>   (gdb)
> 
> with =thread-creating going before prompt, while in sync mode 
> (gdb) follows ^running immediately.

Is this syntax only recently allowed and not yet documented?  I built
the current info docs from CVS and the grammar does not allow for
RESULT-RECORD OUT-OF-BAND-RECORD (gdb) NL.

=thread-created after *running makes lots of sense.  =thread-created
after ^running is a little weird to me.  If ^running is the response
to a command it ought to be followed by a prompt.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Fix MI/async testsuite

[Vladimir Prus]

On Sunday 04 May 2008 20:33:21 Daniel Jacobowitz wrote:
> On Sun, May 04, 2008 at 04:18:14PM +0400, Vladimir Prus wrote:
> > 
> > My previous patches to add =thread-created have broken MI testsuite
> > in async mode, since in async mode, the order of output is somewhat
> > different and the output for -exec-run is:
> > 
> >   ^running
> >   =thread-created
> >   (gdb)
> > 
> > with =thread-creating going before prompt, while in sync mode 
> > (gdb) follows ^running immediately.
> 
> Is this syntax only recently allowed and not yet documented?  I built
> the current info docs from CVS and the grammar does not allow for
> RESULT-RECORD OUT-OF-BAND-RECORD (gdb) NL.

Guess this is because I did not update the grammar per earliner discussion.
We should have RESULT-RECORD, OUT-OF-BAND-RECORD and PROMPT be independent,
and allowed to appear in any order.

> =thread-created after *running makes lots of sense.  =thread-created
> after ^running is a little weird to me.  If ^running is the response
> to a command it ought to be followed by a prompt.

Per current grammar, yes. In principle, no -- prompt indicates that gdb
is ready to accept further input, and should be printed, naturally, when
gdb is ready to accept more input -- which is not necessary right after
printing "^running".

- Volodya

Re: Fix MI/async testsuite

[Daniel Jacobowitz]

On Sun, May 04, 2008 at 08:48:20PM +0400, Vladimir Prus wrote:
> Guess this is because I did not update the grammar per earliner discussion.
> We should have RESULT-RECORD, OUT-OF-BAND-RECORD and PROMPT be independent,
> and allowed to appear in any order.
> 
> > =thread-created after *running makes lots of sense.  =thread-created
> > after ^running is a little weird to me.  If ^running is the response
> > to a command it ought to be followed by a prompt.
> 
> Per current grammar, yes. In principle, no -- prompt indicates that gdb
> is ready to accept further input, and should be printed, naturally, when
> gdb is ready to accept more input -- which is not necessary right after
> printing "^running".

Why should we print ^running before we are ready for more input?

*running, yes, soon as the target starts running.  But ^running is the
result of the command and should show up when the command is done,
shouldn't it?

In other words, the current version:

`OUTPUT ==>'
     `( OUT-OF-BAND-RECORD )* [ RESULT-RECORD ] "(gdb)" NL'

`RESULT-RECORD ==>'
     ` [ TOKEN ] "^" RESULT-CLASS ( "," RESULT )* NL'

Changed to this:

`OUTPUT ==>'
     `OUT-OF-BAND-RECORD | RESULT-RECORD'

`RESULT-RECORD ==>'
     ` [ TOKEN ] "^" RESULT-CLASS ( "," RESULT )* NL "(gdb)" NL'

-- 
Daniel Jacobowitz
CodeSourcery

Re: Fix MI/async testsuite

[Daniel Jacobowitz]

On Sun, May 04, 2008 at 01:14:30PM -0400, Daniel Jacobowitz wrote:
> Why should we print ^running before we are ready for more input?
> 
> *running, yes, soon as the target starts running.  But ^running is the
> result of the command and should show up when the command is done,
> shouldn't it?

Duh, this is because of sync mode, right?  Anyway, it seems like "gdb
accepts input after -exec-continue" and "gdb uses *running instead of
^running" should have the same condition, to avoid this weird output.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Fix MI/async testsuite

[Vladimir Prus]

On Sunday 04 May 2008 21:22:34 Daniel Jacobowitz wrote:
> On Sun, May 04, 2008 at 01:14:30PM -0400, Daniel Jacobowitz wrote:
> > Why should we print ^running before we are ready for more input?
> > 
> > *running, yes, soon as the target starts running.  But ^running is the
> > result of the command and should show up when the command is done,
> > shouldn't it?
> 
> Duh, this is because of sync mode, right?  Anyway, it seems like "gdb
> accepts input after -exec-continue" and "gdb uses *running instead of
> ^running" should have the same condition, to avoid this weird output.

Well, ideally, ^running should not exist. When gdb is done with a command,
it should always print ^done, and since it's done with a command, print a
prompt. Unfortunately, right now ^running exists and does something fairly
strange:

- in sync mode, you get "^running" + "(gdb)" before even trying to resume
target
- in async mode you get "^running" + random output + "(gdb)"
- in async mode when running CLI command, you get "^running" + "^done"

This is a mess, but I don't think we should/can fix this mess without
going to MI3.

- Volodya

Re: Fix MI/async testsuite

[Daniel Jacobowitz]

On Sun, May 04, 2008 at 09:38:01PM +0400, Vladimir Prus wrote:
> Well, ideally, ^running should not exist. When gdb is done with a command,
> it should always print ^done, and since it's done with a command, print a
> prompt. Unfortunately, right now ^running exists and does something fairly
> strange:
> 
> - in sync mode, you get "^running" + "(gdb)" before even trying to resume
> target
> - in async mode you get "^running" + random output + "(gdb)"
> - in async mode when running CLI command, you get "^running" + "^done"
> 
> This is a mess, but I don't think we should/can fix this mess without
> going to MI3.

For MI2, why can't we leave ^running always followed by a prompt?  We
fail to accept input at that prompt in sync mode, which is a known
bug, but that's life.

I don't think having ^result followed by =EVENT followed by (gdb)
makes sense, and it's a new broken behavior, not an old one.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Fix MI/async testsuite

[Vladimir Prus]

On Sunday 04 May 2008 23:56:40 Daniel Jacobowitz wrote:
> On Sun, May 04, 2008 at 09:38:01PM +0400, Vladimir Prus wrote:
> > Well, ideally, ^running should not exist. When gdb is done with a command,
> > it should always print ^done, and since it's done with a command, print a
> > prompt. Unfortunately, right now ^running exists and does something fairly
> > strange:
> > 
> > - in sync mode, you get "^running" + "(gdb)" before even trying to resume
> > target
> > - in async mode you get "^running" + random output + "(gdb)"
> > - in async mode when running CLI command, you get "^running" + "^done"
> > 
> > This is a mess, but I don't think we should/can fix this mess without
> > going to MI3.
> 
> For MI2, why can't we leave ^running 

We can't "leave" it, because in async mode ^running is not immediately followed
by a prompt, now, and before any my changes. 

> always followed by a prompt?  We 
> fail to accept input at that prompt in sync mode, which is a known
> bug, but that's life.

I sure can make all ^running be followed by prompt, but that would be "fixing"
code to be as buggy as the other code. Does it worth the time?

> I don't think having ^result followed by =EVENT followed by (gdb)
> makes sense, 

I think it does -- and the MI spec I've just posted explicitly calls for
such behaviour for run commands:

1. First you get ^done, which means "Okay, nothing else to do about this command"
2. Then you get *running, =whatever, ..., *stopped

In async mode, you get prompt immediately after (1) -- because it's where gdb
is ready to accept commands. In sync mode, you get prompt after (2). Of course,
we can print ^done only after (2) in that case, but does it make sense?

- Volodya

Re: Fix MI/async testsuite

[Daniel Jacobowitz]

Sorry, I shouldn't have dropped this conversation.  Now I'm going to
have to figure out all the issues again...

On Mon, May 05, 2008 at 12:40:47PM +0400, Vladimir Prus wrote:
> On Sunday 04 May 2008 23:56:40 Daniel Jacobowitz wrote:
> > For MI2, why can't we leave ^running 
> 
> We can't "leave" it, because in async mode ^running is not immediately followed
> by a prompt, now, and before any my changes. 
> 
> > always followed by a prompt?  We 
> > fail to accept input at that prompt in sync mode, which is a known
> > bug, but that's life.
> 
> I sure can make all ^running be followed by prompt, but that would be "fixing"
> code to be as buggy as the other code. Does it worth the time?

Working async mode is a new feature.  Previous releases of GDB always
had ^running followed by a prompt, and I think that's the right thing
to output if you're going to use ^running.

> > I don't think having ^result followed by =EVENT followed by (gdb)
> > makes sense, 
> 
> I think it does -- and the MI spec I've just posted explicitly calls for
> such behaviour for run commands:
> 
> 1. First you get ^done, which means "Okay, nothing else to do about this command"
> 2. Then you get *running, =whatever, ..., *stopped

Why is *running after ^done, anyway?

> In async mode, you get prompt immediately after (1) -- because it's where gdb
> is ready to accept commands. In sync mode, you get prompt after (2). Of course,
> we can print ^done only after (2) in that case, but does it make sense?

There won't be any ^done will there?  ^running, (gdb), *stopped,
(gdb).  And in async mode I'd expect something like

-exec-start
*running
^done
(gdb)
[pause while things run]
*stopped
[I don't remember if we get a prompt here.]

-- 
Daniel Jacobowitz
CodeSourcery