Re: linux native async mode support

Vladimir Prus
2008-04-04T11:47:32Z

On Tuesday 01 April 2008 23:40:22 you wrote:
> > >     send_gdb "start\n"
> > >     gdb_expect {
> > >         -re ".*\\^running\r\n\\^done\r\n$mi_gdb_prompt" {
> >
> > I don't think this is right. MI is (supposed to be) extensible. In particular, new async
> > notification may be added. The above will break if any notification will be emitted
> > between ^running and ^done and the prompt.
>
> I try to make Emacs (the frontend) as tolerant as possible to changes in MI
> output, in the hope that future changes, e.g., new fields don't break released
> versions of Emacs. This is a test, however, and it's purpose *is* to detect
> changes in Gdb output. If they are undesirable changes then it's done its job
> and detected a regression.

By definition, MI is extensible, and a test for feature X should only fail if feature
X got broken, not when new fields or notification are added by feature Y. We already
had "but how can we update all MI testsuite for new field" discussions here.

> If the changes are deliberate, we update the test.
> There's no way to know, in advance, which type the change is and the danger of
> making the regexp too general is that we miss a real failure.
>
> > > ...
> > >     send_gdb "next\n"
> > >     gdb_expect {
> > >         -re "\\^running\r\n\\^done\r\n$mi_gdb_prompt" {
> > >             gdb_expect {
> > >                 -re "\\*stopped,reason=\"end-stepping-range\",thread-id=\"0\",frame=\{addr=\"$hex\",func=\"main\",args=\\\[\\\],file=\".*basics.c\",line=\"$line_main_next\"\}\r\n$mi_gdb_prompt$"
> > {
> > >                     pass "Asynchronous response after next command"
> > >                 }
> > >                 -re ".*$mi_gdb_prompt$" {
> > >                     fail "Asynchronous response after next command (2)"
> > >                 }
> > >                 timeout {
> > >                     fail "Asynchronous response after next command (timeout 2)"
> > >                 }
> > >             }
> > >         }
> >
> > It appears there's a lot of duplicated logic above. Can we please have
> > factor it out into a helper function? This is not for the sake of abstract
> > clarify -- I've already spend hours updating the current MI testsuite for
> > non-stop mode.
>
> The helper functions that you have written for common sequences are a good
> idea as they need only be updated in one place but the three here are the
> only ones of their kind (they output an extra "^done" over MI commands like
> -exec-next). Not really worth a dedicated helper function do you agree?

Why there's extra "^done"? Presently, each command is supposed to have
either "^running" or "^done", not both. I realize that fixing this requires
introducing "*running", so that we still know that the target is resumed.
I have the patch for *running basically done, so I suggest that I submit it,
and then we'll have just ^done in this example.

BTW, I'm not even sure that "^done" vs. "^running" + "^done" is so big
difference that a helper function cannot be introduced.

- Volodya