linux native async mode support

[Vladimir Prus]

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