This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: linux native async mode support
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