This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [resubmit] gdb.base, r*.exp thru w*.exp
Jan Kratochvil wrote:
On Thu, 20 May 2010 23:37:49 +0200, Michael Snyder wrote:
Jan Kratochvil wrote:
On Thu, 20 May 2010 22:29:47 +0200, Michael Snyder wrote:
+ -re ".*in main after func1.*$gdb_prompt $" {
Sorry for not a complete review but for this case there should be:
-re ".*in main after func1.*\r\n$gdb_prompt $" {
or lib/gdb.exp proc gdb_test is using:
-re ".*in main after func1.*[\r\n]+$gdb_prompt $" {
as just "$gdb_prompt $" is needlessly weak in practical cases causing false
positives.
Thanks for the review -- but I don't follow you.
What is it about this particular case that you think requires
disambiguating? Or are you saying this in general?
It was said in general.
There could be for example output
(gdb) return
Make func1 return now? (y or n) y
#0 main () at ./gdb.base/return.c:31
31 printf("in debugger (gdb) after func1\n");
(gdb)
and if expect would read(2) just the part
(gdb) return
Make func1 return now? (y or n) y
#0 main () at ./gdb.base/return.c:31
31 printf("in debugger (gdb)
before the next part of input arrives it can have a false termination of
waiting on the prompt.
That can happens for example for "info set" where the output contains text:
prompt: Gdb's prompt is "(gdb) ".
(In this specific testcase there is no "(gdb) " contained in the output so it
cannot have a false positive. But examining all the testcases would be
difficult. Also I understand even "\r\n(gdb) " can have a false positive on
some random output.)
Well, this is a very common and ancient idiom that is used
everywhere throughout the test suite.
You have to assume that we don't care about anything between
the ".*" and the "$gdb_prompt $". If we do, the test is wrong,
but if it consumes more output than it was meant to, the
following tests will fail.