aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/README
diff options
context:
space:
mode:
authorTom de Vries <tdevries@suse.de>2021-10-09 18:53:12 +0200
committerTom de Vries <tdevries@suse.de>2021-10-09 18:53:12 +0200
commitfa9ce2c143ce7ee6bc4f22a0577fe5c0858beddd (patch)
tree9fbe732c77013df72d0fdc67a47490a7a828d500 /gdb/testsuite/README
parentf9edf608302736ec68bc80d6b6bc7d0f54171554 (diff)
downloadgdb-fa9ce2c143ce7ee6bc4f22a0577fe5c0858beddd.zip
gdb-fa9ce2c143ce7ee6bc4f22a0577fe5c0858beddd.tar.gz
gdb-fa9ce2c143ce7ee6bc4f22a0577fe5c0858beddd.tar.bz2
[gdb/testsuite] Add check-readmore
Consider the gdb output: ... 27 return SYSCALL_CANCEL (nanosleep, requested_time, remaining);^M (gdb) ^M Thread 2 "run-attach-whil" stopped.^M ... When trying to match the gdb prompt using gdb_test which uses '$gdb_prompt $', it may pass or fail. This sort of thing needs to be fixed (see commit b0e2f96b56b), but there's currently no way to reliably find this type of FAILs. We have check-read1, but that one actually make the test pass reliably. We need something like the opposite of check-read1: something that makes expect read a bit slower, or more exhaustively. Add a new test target check-readmore that implements this. There are two methods of implementing this in read1.c: - the first method waits a bit before doing a read - the second method does a read and then decides whether to return or to wait a bit and do another read, and so on. The second method is potentially faster, has less risc of timeout and could potentially detect more problems. The first method has a simpler implementation. The second method is enabled by default. The default waiting period is 10 miliseconds. The first method can be enabled using: ... $ export READMORE_METHOD=1 ... and the waiting period can be specified in miliseconds using: ... $ export READMORE_SLEEP=9 ... Also a log file can be specified using: ... $ export READMORE_LOG=$(pwd -P)/LOG ... Tested on x86_64-linux. Testing with check-readmore showed these regressions: ... FAIL: gdb.base/bp-cmds-continue-ctrl-c.exp: run: stop with control-c (continue) FAIL: gdb.base/bp-cmds-continue-ctrl-c.exp: attach: stop with control-c (continue) ... I have not been able to find a problem in the test-case, and I think it's the nature of both the test-case and readmore that makes it run longer. Make these pass by increasing the alarm timeout from 60 to 120 seconds. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27957
Diffstat (limited to 'gdb/testsuite/README')
-rw-r--r--gdb/testsuite/README2
1 files changed, 1 insertions, 1 deletions
diff --git a/gdb/testsuite/README b/gdb/testsuite/README
index 862f423..7552774 100644
--- a/gdb/testsuite/README
+++ b/gdb/testsuite/README
@@ -361,7 +361,7 @@ fail, it can also have the effect of making otherwise failing tests pass.
This happens f.i. if the test is trying to match a gdb prompt using an end of
input marker "${gdb_prompt} $" and there is output after the gdb prompt. This
may either pass or fail in normal operation, but using check-read1 will ensure
-that it passes.
+that it passes. Use check-readmore to detect this type of failure.
Testsuite Configuration
***********************