* [patch] testsuite: MI: racy results in async mode (PR testsuite/12649)
@ 2011-10-27 10:16 Jan Kratochvil
2011-10-27 16:49 ` Tom Tromey
2011-11-01 15:40 ` [patch] testsuite: MI: racy results in async mode (PR testsuite/12649) Doug Evans
0 siblings, 2 replies; 16+ messages in thread
From: Jan Kratochvil @ 2011-10-27 10:16 UTC (permalink / raw)
To: gdb-patches; +Cc: Marek Polacek
Hi,
I was looking at some systematic-like regression but it was just a race again.
The fix is ugly but it cannot be done better before there is a generic MI
client parser deployed for the testsuite.
$prompt_re is "" in this case, therefore the =breakpoint-deleted async
notification is randomly left or swallowed by the end of regex in
mi_expect_stop:
-re "\\*stopped,${r}${a}${bn}frame=\{addr=\"$hex\",func=\"$func\",args=$args,file=\"$any$file\",fullname=\"${fullname_syntax}$file\",line=\"($line)\"\}$after_stopped,thread-id=\"$decimal\",stopped-threads=$any\r\n($thread_selected_re|$breakpoint_re)*$prompt_re" {
No regressions on {x86_64,x86_64-m32,i686}-fedora16pre-linux-gnu and with
gdbserver.
I will check it in in some time.
Thanks,
Jan
PASS->FAIL log during a random regression:
=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x0804859b",func="main",file="gdb/testsuite/gdb.mi/nsmoribund.c",fullname="gdb/testsuite/gdb.mi/nsmoribund.c",line="55",times="1",original-location="main"}^M
-*stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={addr="0x0804859b",func="main",args=[{name="argc",value="1"},{name="argv",value="0xffffd004"}],file="gdb/testsuite/gdb.mi/nsmoribund.c",fullname="gdb/testsuite/gdb.mi/nsmoribund.c",line="55"},thread-id="1",stopped-threads=["1"],core="7"^M
-=breakpoint-deleted,id="1"^M
+*stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={addr="0x0804859b",func="main",args=[{name="argc",value="1"},{name="argv",value="0xffffd004"}],file="gdb/testsuite/gdb.mi/nsmoribund.c",fullname="gdb/testsuite/gdb.mi/nsmoribund.c",line="55"},thread-id="1",stopped-threads=["1"],core="1"^M
PASS: gdb.mi/mi-nsmoribund.exp: mi runto main
Expecting: 222\^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr=".*",func="thread_function",file=".*",fullname=".*",line=".*",times="0",original-location=".*"}
Expecting: ^(222-break-insert nsmoribund\.c:39[^M
]+)?(222\^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr=".*",func="thread_function",file=".*",fullname=".*",line=".*",times="0",original-location=".*"}[^M
]+[(]gdb[)] ^M
[ ]*)
+=breakpoint-deleted,id="1"^M
222-break-insert nsmoribund.c:39^M
222^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x08048552",func="thread_function",file="gdb/testsuite/gdb.mi/nsmoribund.c",fullname="gdb/testsuite/gdb.mi/nsmoribund.c",line="39",times="0",original-location="nsmoribund.c:39"}^M
(gdb) ^M
-PASS: gdb.mi/mi-nsmoribund.exp: breakpoint at thread_function
+FAIL: gdb.mi/mi-nsmoribund.exp: breakpoint at thread_function
-exec-continue --all^M
^running^M
*running,thread-id="1"^M
gdb/testsuite/
2011-10-27 Jan Kratochvil <jan.kratochvil@redhat.com>
* lib/mi-support.exp (breakpoint_re): Suppress match reporting.
(mi_gdb_test): Import globals thread_selected_re
and breakpoint_re. Expect them optionally at the regex start.
--- a/gdb/testsuite/lib/mi-support.exp
+++ b/gdb/testsuite/lib/mi-support.exp
@@ -32,7 +32,7 @@ set MIFLAGS "-i=mi"
set thread_selected_re "=thread-selected,id=\"\[0-9\]+\"\r\n"
set library_loaded_re "=library-loaded\[^\n\]+\"\r\n"
-set breakpoint_re "=(breakpoint-created|breakpoint-deleted)\[^\n\]+\"\r\n"
+set breakpoint_re "=(?:breakpoint-created|breakpoint-deleted)\[^\n\]+\"\r\n"
#
# mi_gdb_exit -- exit the GDB, killing the target program if necessary
@@ -576,7 +576,7 @@ proc mi_gdb_test { args } {
global verbose
global mi_gdb_prompt
global GDB expect_out
- global inferior_exited_re
+ global inferior_exited_re thread_selected_re breakpoint_re
upvar timeout timeout
set command [lindex $args 0]
@@ -668,7 +668,7 @@ proc mi_gdb_test { args } {
gdb_start
set result -1
}
- -re "^($string_regex\[\r\n\]+)?($pattern\[\r\n\]+$mi_gdb_prompt\[ \]*)" {
+ -re "^(?:$thread_selected_re|$breakpoint_re)*($string_regex\[\r\n\]+)?($pattern\[\r\n\]+$mi_gdb_prompt\[ \]*)" {
# At this point, $expect_out(1,string) is the MI input command.
# and $expect_out(2,string) is the MI output command.
# If $expect_out(1,string) is "", then there was no MI input command here.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [patch] testsuite: MI: racy results in async mode (PR testsuite/12649)
2011-10-27 10:16 [patch] testsuite: MI: racy results in async mode (PR testsuite/12649) Jan Kratochvil
@ 2011-10-27 16:49 ` Tom Tromey
2011-10-28 8:51 ` [commit] " Jan Kratochvil
2011-11-01 15:40 ` [patch] testsuite: MI: racy results in async mode (PR testsuite/12649) Doug Evans
1 sibling, 1 reply; 16+ messages in thread
From: Tom Tromey @ 2011-10-27 16:49 UTC (permalink / raw)
To: Jan Kratochvil; +Cc: gdb-patches, Marek Polacek
>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
Jan> 2011-10-27 Jan Kratochvil <jan.kratochvil@redhat.com>
Jan> * lib/mi-support.exp (breakpoint_re): Suppress match reporting.
Jan> (mi_gdb_test): Import globals thread_selected_re
Jan> and breakpoint_re. Expect them optionally at the regex start.
Thanks for doing this.
I've been seeing these in my regression tests.
Tom
^ permalink raw reply [flat|nested] 16+ messages in thread
* [commit] [patch] testsuite: MI: racy results in async mode (PR testsuite/12649)
2011-10-27 16:49 ` Tom Tromey
@ 2011-10-28 8:51 ` Jan Kratochvil
2011-10-29 10:36 ` [patch] testsuite: MI: racy results in async mode #2 Jan Kratochvil
0 siblings, 1 reply; 16+ messages in thread
From: Jan Kratochvil @ 2011-10-28 8:51 UTC (permalink / raw)
To: Tom Tromey; +Cc: gdb-patches, Marek Polacek
On Thu, 27 Oct 2011 18:45:18 +0200, Tom Tromey wrote:
> >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
>
> Jan> 2011-10-27 Jan Kratochvil <jan.kratochvil@redhat.com>
> Jan> * lib/mi-support.exp (breakpoint_re): Suppress match reporting.
> Jan> (mi_gdb_test): Import globals thread_selected_re
> Jan> and breakpoint_re. Expect them optionally at the regex start.
>
> Thanks for doing this.
> I've been seeing these in my regression tests.
Checked in:
http://sourceware.org/ml/gdb-cvs/2011-10/msg00202.html
Thanks,
Jan
^ permalink raw reply [flat|nested] 16+ messages in thread
* [patch] testsuite: MI: racy results in async mode #2
2011-10-28 8:51 ` [commit] " Jan Kratochvil
@ 2011-10-29 10:36 ` Jan Kratochvil
2011-10-29 12:10 ` Marek Polacek
` (2 more replies)
0 siblings, 3 replies; 16+ messages in thread
From: Jan Kratochvil @ 2011-10-29 10:36 UTC (permalink / raw)
To: Tom Tromey; +Cc: gdb-patches, Marek Polacek
On Fri, 28 Oct 2011 10:32:56 +0200, Jan Kratochvil wrote:
> > Jan> 2011-10-27 Jan Kratochvil <jan.kratochvil@redhat.com>
> > Jan> * lib/mi-support.exp (breakpoint_re): Suppress match reporting.
> > Jan> (mi_gdb_test): Import globals thread_selected_re
> > Jan> and breakpoint_re. Expect them optionally at the regex start.
[...]
> Checked in:
> http://sourceware.org/ml/gdb-cvs/2011-10/msg00202.html
Unfortunately it still does not work (but it is no longer reproducible by the
testsuite/12649 "read1" way).
-*stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={addr="0x080485fd",func="main",args=[{name="argc",value="1"},{name="argv",value="0xffffd1e4"}],file="gdb/testsuite/gdb.mi/non-stop.c",fullname="gdb/testsuite/gdb.mi/non-stop.c",line="86"},thread-id="1",stopped-threads=["1"],core="5"^M
+*stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={addr="0x080485fd",func="main",args=[{name="argc",value="1"},{name="argv",value="0xffffd1c4"}],file="gdb/testsuite/gdb.mi/non-stop.c",fullname="gdb/testsuite/gdb.mi/non-stop.c",line="86"},thread-id="1",stopped-threads=["1"],core="0"^M
+=breakpoint-deleted,id="1"^M
PASS: gdb.mi/mi-nonstop.exp: mi runto main
Expecting: 222\^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr=".*",func="break_at_me",file=".*",fullname=".*",line=".*",times="0",original-location=".*"}
Expecting: ^(222-break-insert break_at_me[^M
]+)?(222\^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr=".*",func="break_at_me",file=".*",fullname=".*",line=".*",times="0",original-location=".*"}[^M
]+[(]gdb[)] ^M
[ ]*)
222-break-insert break_at_me^M
-=breakpoint-deleted,id="1"^M
222^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x08048537",func="break_at_me",file="gdb/testsuite/gdb.mi/non-stop.c",fullname="gdb/testsuite/gdb.mi/non-stop.c",line="41",times="0",original-location="break_at_me"}^M
(gdb) ^M
-FAIL: gdb.mi/mi-nonstop.exp: breakpoint at marker
+PASS: gdb.mi/mi-nonstop.exp: breakpoint at marker
Therefore proposing the attached way.
No regressions on {x86_64,x86_64-m32,i686}-fedora16pre-linux-gnu and with gdbserver.
Thanks,
Jan
gdb/testsuite/
2011-10-29 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix racy FAILs.
* lib/mi-support.exp (mi_gdb_test): Replace thread_selected_re and
breakpoint_re globals import by async. Set string_regex to .* for
async. Remove the optional thread_selected_re and breakpoint_re
globals expectations.
--- a/gdb/testsuite/lib/mi-support.exp
+++ b/gdb/testsuite/lib/mi-support.exp
@@ -576,7 +576,7 @@ proc mi_gdb_test { args } {
global verbose
global mi_gdb_prompt
global GDB expect_out
- global inferior_exited_re thread_selected_re breakpoint_re
+ global inferior_exited_re async
upvar timeout timeout
set command [lindex $args 0]
@@ -651,6 +651,11 @@ proc mi_gdb_test { args } {
set tmt 60;
}
}
+ if {$async} {
+ # With $prompt_re "" there may come arbitrary asynchronous response
+ # from the previous command, before or after $string_regex.
+ set string_regex ".*"
+ }
verbose -log "Expecting: ^($string_regex\[\r\n\]+)?($pattern\[\r\n\]+$mi_gdb_prompt\[ \]*)"
gdb_expect $tmt {
-re "\\*\\*\\* DOSEXIT code.*" {
@@ -668,7 +673,7 @@ proc mi_gdb_test { args } {
gdb_start
set result -1
}
- -re "^(?:$thread_selected_re|$breakpoint_re)*($string_regex\[\r\n\]+)?($pattern\[\r\n\]+$mi_gdb_prompt\[ \]*)" {
+ -re "^($string_regex\[\r\n\]+)?($pattern\[\r\n\]+$mi_gdb_prompt\[ \]*)" {
# At this point, $expect_out(1,string) is the MI input command.
# and $expect_out(2,string) is the MI output command.
# If $expect_out(1,string) is "", then there was no MI input command here.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [patch] testsuite: MI: racy results in async mode #2
2011-10-29 10:36 ` [patch] testsuite: MI: racy results in async mode #2 Jan Kratochvil
@ 2011-10-29 12:10 ` Marek Polacek
2011-10-29 12:15 ` Marek Polacek
2011-11-01 16:20 ` Tom Tromey
2011-11-01 16:26 ` Marek Polacek
2 siblings, 1 reply; 16+ messages in thread
From: Marek Polacek @ 2011-10-29 12:10 UTC (permalink / raw)
To: Jan Kratochvil; +Cc: Tom Tromey, gdb-patches
On 10/29/2011 12:09 PM, Jan Kratochvil wrote:
> Therefore proposing the attached way.
I bet there are still others failures like these. I'll try to use read1 (or
something similar like read with (rand() % count) + 1) to discover more of
them.
Marek
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] testsuite: MI: racy results in async mode #2
2011-10-29 12:10 ` Marek Polacek
@ 2011-10-29 12:15 ` Marek Polacek
2011-10-29 15:09 ` Jan Kratochvil
0 siblings, 1 reply; 16+ messages in thread
From: Marek Polacek @ 2011-10-29 12:15 UTC (permalink / raw)
To: Jan Kratochvil; +Cc: Tom Tromey, gdb-patches
On 10/29/2011 12:36 PM, Marek Polacek wrote:
> I bet there are still others failures like these. I'll try to use read1 (or
> something similar like read with (rand() % count) + 1) to discover more of
> them.
Well I've run $ runtest -a gdb.mi/*.exp with read1 10+ times and didn't find
any race failures.
Marek
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] testsuite: MI: racy results in async mode #2
2011-10-29 12:15 ` Marek Polacek
@ 2011-10-29 15:09 ` Jan Kratochvil
2011-10-29 16:01 ` Marek Polacek
0 siblings, 1 reply; 16+ messages in thread
From: Jan Kratochvil @ 2011-10-29 15:09 UTC (permalink / raw)
To: Marek Polacek; +Cc: Tom Tromey, gdb-patches
On Sat, 29 Oct 2011 14:09:52 +0200, Marek Polacek wrote:
> Well I've run $ runtest -a gdb.mi/*.exp with read1 10+ times and didn't find
> any race failures.
Unfortunately this problem is unrelated to "read1".
The problem is GDB will:
write: *stopped,reason...
write: =breakpoint-deleted,...
read: <waits for input>
while expect will:
read: *stopped,reason... + everything available incl. =breakpoint-deleted
write: 222-break-insert break_at_me
read: ... now either =breakpoint-deleted is read or local 222-break-insert pty echo
In normal cases the first expect's read will read even =breakpoint-deleted.
With the read1 hack =breakpoint-deleted is not read in, it is kept in some
internal pty buffer. But it is already in that pty buffer so when expect
sends 222-break-insert the pty echoes 222-break-insert already _after_ the
=breakpoint-deleted string so no reproducibility changes with read1.
One can reproduce it by delaying all the writes from GDB. This way everything
gets processed on the expect side (incl. pty write + read of its echo) and
only afterwars =breakpoint-deleted finally arrives.
I have attached this different kind of reproducer to the Bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=12649#c6
Thanks,
Jan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] testsuite: MI: racy results in async mode #2
2011-10-29 15:09 ` Jan Kratochvil
@ 2011-10-29 16:01 ` Marek Polacek
0 siblings, 0 replies; 16+ messages in thread
From: Marek Polacek @ 2011-10-29 16:01 UTC (permalink / raw)
To: Jan Kratochvil; +Cc: Tom Tromey, gdb-patches
On 10/29/2011 04:00 PM, Jan Kratochvil wrote:
> I have attached this different kind of reproducer to the Bug:
> http://sourceware.org/bugzilla/show_bug.cgi?id=12649#c6
PASSes->FAILs with writew.so on x86_64-unknown-linux-gnu:
@@ -16333,7 +16333,7 @@
PASS: gdb.mi/mi-nonstop.exp: successfully compiled posix threads test case
PASS: gdb.mi/mi-nonstop.exp: breakpoint at main
PASS: gdb.mi/mi-nonstop.exp: mi runto main
-PASS: gdb.mi/mi-nonstop.exp: breakpoint at marker
+FAIL: gdb.mi/mi-nonstop.exp: breakpoint at marker
PASS: gdb.mi/mi-nonstop.exp: w0,i0 stop
PASS: gdb.mi/mi-nonstop.exp: w1,i0 stop
PASS: gdb.mi/mi-nonstop.exp: thread state, stop 1
@@ -16377,7 +16377,7 @@
PASS: gdb.mi/mi-nsintrall.exp: successfully compiled posix threads test case
PASS: gdb.mi/mi-nsintrall.exp: breakpoint at main
PASS: gdb.mi/mi-nsintrall.exp: mi runto main
-PASS: gdb.mi/mi-nsintrall.exp: breakpoint at thread_function
+FAIL: gdb.mi/mi-nsintrall.exp: breakpoint at thread_function
PASS: gdb.mi/mi-nsintrall.exp: stop 0
PASS: gdb.mi/mi-nsintrall.exp: stop 1
PASS: gdb.mi/mi-nsintrall.exp: stop 2
@@ -16401,7 +16401,7 @@
PASS: gdb.mi/mi-nsmoribund.exp: successfully compiled posix threads test case
PASS: gdb.mi/mi-nsmoribund.exp: breakpoint at main
PASS: gdb.mi/mi-nsmoribund.exp: mi runto main
-PASS: gdb.mi/mi-nsmoribund.exp: breakpoint at thread_function
+FAIL: gdb.mi/mi-nsmoribund.exp: breakpoint at thread_function
PASS: gdb.mi/mi-nsmoribund.exp: stop 0
PASS: gdb.mi/mi-nsmoribund.exp: stop 1
PASS: gdb.mi/mi-nsmoribund.exp: stop 2
@@ -16423,7 +16423,7 @@
PASS: gdb.mi/mi-nsthrexec.exp: successfully compiled posix threads test case
PASS: gdb.mi/mi-nsthrexec.exp: breakpoint at main
PASS: gdb.mi/mi-nsthrexec.exp: mi runto main
-PASS: gdb.mi/mi-nsthrexec.exp: breakpoint at thread_execler
+FAIL: gdb.mi/mi-nsthrexec.exp: breakpoint at thread_execler
PASS: gdb.mi/mi-nsthrexec.exp: stop at thread_execler
PASS: gdb.mi/mi-nsthrexec.exp: thread state, execler stopped, main running
PASS: gdb.mi/mi-nsthrexec.exp: interrupt main thread
@@ -20337,7 +20337,7 @@
PASS: gdb.threads/watchthreads2.exp: all threads started
PASS: gdb.threads/watchthreads2.exp: watch x
PASS: gdb.threads/watchthreads2.exp: set var test_ready = 1
-PASS: gdb.threads/watchthreads2.exp: all threads incremented x
+KFAIL: gdb.threads/watchthreads2.exp: gdb can drop watchpoints in multithreaded app (PRMS: gdb/10116)
Fortunately, there aren't many of them.
Marek
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] testsuite: MI: racy results in async mode #2
2011-10-29 10:36 ` [patch] testsuite: MI: racy results in async mode #2 Jan Kratochvil
2011-10-29 12:10 ` Marek Polacek
@ 2011-11-01 16:20 ` Tom Tromey
2011-11-01 20:01 ` [commit] " Jan Kratochvil
2011-11-01 16:26 ` Marek Polacek
2 siblings, 1 reply; 16+ messages in thread
From: Tom Tromey @ 2011-11-01 16:20 UTC (permalink / raw)
To: Jan Kratochvil; +Cc: gdb-patches, Marek Polacek
>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
Jan> Therefore proposing the attached way.
I think if it works then it is clearly better than what we have now.
One other idea would be to send an "output" command so that you could
match some known output to sync up correctly. I'm not sure if this
would always work though.
Tom
^ permalink raw reply [flat|nested] 16+ messages in thread
* [commit] [patch] testsuite: MI: racy results in async mode #2
2011-11-01 16:20 ` Tom Tromey
@ 2011-11-01 20:01 ` Jan Kratochvil
0 siblings, 0 replies; 16+ messages in thread
From: Jan Kratochvil @ 2011-11-01 20:01 UTC (permalink / raw)
To: Tom Tromey, Marek Polacek; +Cc: gdb-patches
On Tue, 01 Nov 2011 17:19:38 +0100, Tom Tromey wrote:
> I think if it works then it is clearly better than what we have now.
OK, checked in so that I can further watch the racy behavior:
http://sourceware.org/ml/gdb-cvs/2011-11/msg00005.html
> One other idea would be to send an "output" command so that you could
> match some known output to sync up correctly. I'm not sure if this
> would always work though.
From some level of difficulty on I would rather prefer the MI parser.
On Tue, 01 Nov 2011 17:26:17 +0100, Marek Polacek wrote:
> This fixes those 5 FAILs I've seen. Tested with writew.so on x86_64-unknown-
> linux-gnu.
Great, thanks.
Regards,
Jan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] testsuite: MI: racy results in async mode #2
2011-10-29 10:36 ` [patch] testsuite: MI: racy results in async mode #2 Jan Kratochvil
2011-10-29 12:10 ` Marek Polacek
2011-11-01 16:20 ` Tom Tromey
@ 2011-11-01 16:26 ` Marek Polacek
2 siblings, 0 replies; 16+ messages in thread
From: Marek Polacek @ 2011-11-01 16:26 UTC (permalink / raw)
To: Jan Kratochvil; +Cc: Tom Tromey, gdb-patches
On 10/29/2011 12:09 PM, Jan Kratochvil wrote:
> Therefore proposing the attached way.
This fixes those 5 FAILs I've seen. Tested with writew.so on x86_64-unknown-
linux-gnu.
Marek
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] testsuite: MI: racy results in async mode (PR testsuite/12649)
2011-10-27 10:16 [patch] testsuite: MI: racy results in async mode (PR testsuite/12649) Jan Kratochvil
2011-10-27 16:49 ` Tom Tromey
@ 2011-11-01 15:40 ` Doug Evans
2011-11-01 16:26 ` Jan Kratochvil
2011-11-01 18:55 ` Tom Tromey
1 sibling, 2 replies; 16+ messages in thread
From: Doug Evans @ 2011-11-01 15:40 UTC (permalink / raw)
To: Jan Kratochvil; +Cc: gdb-patches, Marek Polacek
On Thu, Oct 27, 2011 at 3:15 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> Hi,
>
> I was looking at some systematic-like regression but it was just a race again.
>
> The fix is ugly but it cannot be done better before there is a generic MI
> client parser deployed for the testsuite.
What does "generic MI client parser" mean in this context?
> $prompt_re is "" in this case, therefore the =breakpoint-deleted async
> notification is randomly left or swallowed by the end of regex in
> mi_expect_stop:
> -re "\\*stopped,${r}${a}${bn}frame=\{addr=\"$hex\",func=\"$func\",args=$args,file=\"$any$file\",fullname=\"${fullname_syntax}$file\",line=\"($line)\"\}$after_stopped,thread-id=\"$decimal\",stopped-threads=$any\r\n($thread_selected_re|$breakpoint_re)*$prompt_re" {
>
> No regressions on {x86_64,x86_64-m32,i686}-fedora16pre-linux-gnu and with
> gdbserver.
>
> I will check it in in some time.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [patch] testsuite: MI: racy results in async mode (PR testsuite/12649)
2011-11-01 15:40 ` [patch] testsuite: MI: racy results in async mode (PR testsuite/12649) Doug Evans
@ 2011-11-01 16:26 ` Jan Kratochvil
2011-11-01 18:55 ` Tom Tromey
1 sibling, 0 replies; 16+ messages in thread
From: Jan Kratochvil @ 2011-11-01 16:26 UTC (permalink / raw)
To: Doug Evans; +Cc: gdb-patches, Marek Polacek
On Tue, 01 Nov 2011 16:40:02 +0100, Doug Evans wrote:
> On Thu, Oct 27, 2011 at 3:15 AM, Jan Kratochvil <jan.kratochvil@redhat.com> wrote:
> > The fix is ugly but it cannot be done better before there is a generic MI
> > client parser deployed for the testsuite.
>
> What does "generic MI client parser" mean in this context?
Something what have the regular MI clients (like Nemiver from what Dodji said
and I expect most/all the others).
That is a stateful parser which automatically stores away async responses,
something like XML parsers are but for MI. Either callbacking GDB on found
elements or storing the elements and providing lookup API into them.
Keith said he wrote something like that in TCL but it never got accepted.
Unfortunately it needs to be in TCL to be compatible with the testsuite.
Thanks,
Jan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] testsuite: MI: racy results in async mode (PR testsuite/12649)
2011-11-01 15:40 ` [patch] testsuite: MI: racy results in async mode (PR testsuite/12649) Doug Evans
2011-11-01 16:26 ` Jan Kratochvil
@ 2011-11-01 18:55 ` Tom Tromey
2011-11-01 22:46 ` Doug Evans
1 sibling, 1 reply; 16+ messages in thread
From: Tom Tromey @ 2011-11-01 18:55 UTC (permalink / raw)
To: Doug Evans; +Cc: Jan Kratochvil, gdb-patches, Marek Polacek
>>>>> "Doug" == Doug Evans <dje@google.com> writes:
Jan> The fix is ugly but it cannot be done better before there is a generic MI
Jan> client parser deployed for the testsuite.
Doug> What does "generic MI client parser" mean in this context?
Right now MI parsing in the test suite is done in an ad hoc manner.
E.g., see mi_create_breakpoint.
It would be more robust if we had an MI parser in Tcl so that we could
parse the output as clients do.
As far as I know nobody is planning to actually do this though.
Tom
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [patch] testsuite: MI: racy results in async mode (PR testsuite/12649)
2011-11-01 18:55 ` Tom Tromey
@ 2011-11-01 22:46 ` Doug Evans
2011-11-02 17:31 ` Tom Tromey
0 siblings, 1 reply; 16+ messages in thread
From: Doug Evans @ 2011-11-01 22:46 UTC (permalink / raw)
To: Tom Tromey; +Cc: Jan Kratochvil, gdb-patches, Marek Polacek
On Tue, Nov 1, 2011 at 10:25 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Doug" == Doug Evans <dje@google.com> writes:
>
> Jan> The fix is ugly but it cannot be done better before there is a generic MI
> Jan> client parser deployed for the testsuite.
>
> Doug> What does "generic MI client parser" mean in this context?
>
> Right now MI parsing in the test suite is done in an ad hoc manner.
> E.g., see mi_create_breakpoint.
>
> It would be more robust if we had an MI parser in Tcl so that we could
> parse the output as clients do.
>
> As far as I know nobody is planning to actually do this though.
Not that I'm planning to do this :-), but would an MI parser written
in C that could be exported to Tcl, Python, etc. be of sufficient use
beyond the testsuite to entice someone to write one? One can load C
modules into Tcl, and I'm guessing(!) the glue to make it usable to
the testsuite would be minimal.
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2011-11-02 17:31 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-10-27 10:16 [patch] testsuite: MI: racy results in async mode (PR testsuite/12649) Jan Kratochvil
2011-10-27 16:49 ` Tom Tromey
2011-10-28 8:51 ` [commit] " Jan Kratochvil
2011-10-29 10:36 ` [patch] testsuite: MI: racy results in async mode #2 Jan Kratochvil
2011-10-29 12:10 ` Marek Polacek
2011-10-29 12:15 ` Marek Polacek
2011-10-29 15:09 ` Jan Kratochvil
2011-10-29 16:01 ` Marek Polacek
2011-11-01 16:20 ` Tom Tromey
2011-11-01 20:01 ` [commit] " Jan Kratochvil
2011-11-01 16:26 ` Marek Polacek
2011-11-01 15:40 ` [patch] testsuite: MI: racy results in async mode (PR testsuite/12649) Doug Evans
2011-11-01 16:26 ` Jan Kratochvil
2011-11-01 18:55 ` Tom Tromey
2011-11-01 22:46 ` Doug Evans
2011-11-02 17:31 ` Tom Tromey
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox