This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] New thread testcase.
- From: Michael Snyder <msnyder at redhat dot com>
- To: Manoj Iyer <manjo at austin dot ibm dot com>
- Cc: Michael Chastain <mec dot gnu at mindspring dot com>, gdb-patches at sources dot redhat dot com, gilliam at us dot ibm dot com
- Date: Thu, 12 Aug 2004 00:26:28 +0000
- Subject: Re: [RFC] New thread testcase.
- Organization: Red Hat, Inc.
- References: <4117F82B.nail1N111PN0T@mindspring.com> <Pine.LNX.4.58.0408091818400.18782@lazy>
Hello Manoj,
#
# step through the thread function.
#
send_gdb "step\n"
gdb_expect {
-re "39.*sprintf.* .*\r\n$gdb_prompt $" {
pass "step to next instruction in tf";
}
-re ".*$gdb_prompt $" {
fail "step to next instruction in tf";
return 1;
}
timeout {
fail "step to next instruction in tf (timeout)";
return 1;
}
}
This will probably work as written, but it hints at a faulty
assumption that might lead it to break if the test is modified
in the future.
When you say "step", you allow the opportunity for the inferior
to switch thread contexts. At present there are only two threads,
and no other breakpoints exist that might be hit, but if that were
not the case, the next stop event could be at another breakpoint,
in another thread. This would not be a bug, and should not cause
a fail. It's expected behavior.
I suppose this could be addressed with a comment, warning the
future maintainer to take it into consideration if more threads
or breakpoints are added.
But like Andrew, I would also like to know what the expected
failure is -- what used to happen before the kernel bug was
fixed? A comment explaining that would be welcome too.
Michael Snyder