From: Simon Marchi Date: Fri, 23 Sep 2022 13:45:24 +0000 (-0400) Subject: gdb/testsuite: bump duration for the whole test in do_self_tests X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=687e348e720a1fcd3850324c9f0ce20b97b456b5;p=binutils-gdb.git gdb/testsuite: bump duration for the whole test in do_self_tests When running gdb.gdb/python-helper.exp, I get some timeouts: continue Continuing. print 1 FAIL: gdb.gdb/python-helper.exp: hit breakpoint in outer gdb (timeout) At this time, GDB is actually processing the stop and reading in some CUs. selftest_setup does bump the timeout, but it's not for the whole test. Since debugging GDB with GDB is (unfortunately) a bit slow, bump the timeout for the whole duration of the setup and body. On my optimized build, the command takes just a bit more than the current timeout of 10 seconds. But it's much slower if running the test on an unoptimized build, so I think it's necessary to bump the timeout for that in any case. Change-Id: I4d38285870e76c94f9d0bfdb60648a2e7f2cfa5d --- diff --git a/gdb/testsuite/lib/selftest-support.exp b/gdb/testsuite/lib/selftest-support.exp index 138afc0df56..2b17c539a96 100644 --- a/gdb/testsuite/lib/selftest-support.exp +++ b/gdb/testsuite/lib/selftest-support.exp @@ -45,29 +45,14 @@ proc find_gdb { arg } { proc selftest_setup { executable function } { global gdb_prompt - global timeout global INTERNAL_GDBFLAGS # load yourself into the debugger - # This can take a relatively long time, particularly for testing where - # the executable is being accessed over a network, or where gdb does not - # support partial symbols for a particular target and has to load the - # entire symbol table. Set the timeout to 10 minutes, which should be - # adequate for most environments (it *has* timed out with 5 min on a - # SPARCstation SLC under moderate load, so this isn't unreasonable). - # After gdb is started, set the timeout to 30 seconds for the duration - # of this test, and then back to the original value. - - set oldtimeout $timeout - set timeout 600 - verbose "Timeout is now $timeout seconds" 2 global gdb_file_cmd_debug_info set gdb_file_cmd_debug_info "unset" set result [gdb_load $executable] - set timeout $oldtimeout - verbose "Timeout is now $timeout seconds" 2 if { $result != 0 } then { return -1 @@ -85,9 +70,6 @@ proc selftest_setup { executable function } { } # run yourself - # It may take a very long time for the inferior gdb to start (lynx), - # so we bump it back up for the duration of this command. - set timeout 600 set description "run until breakpoint at $function" gdb_test_multiple "run $INTERNAL_GDBFLAGS" "$description" { @@ -99,21 +81,14 @@ proc selftest_setup { executable function } { } -re "vfork: No more processes.*$gdb_prompt $" { fail "$description (out of virtual memory)" - set timeout $oldtimeout - verbose "Timeout is now $timeout seconds" 2 return -1 } -re ".*$gdb_prompt $" { fail "$description" - set timeout $oldtimeout - verbose "Timeout is now $timeout seconds" 2 return -1 } } - set timeout $oldtimeout - verbose "Timeout is now $timeout seconds" 2 - return 0 } @@ -159,9 +134,14 @@ proc do_self_tests {function body} { gdb_start set file [remote_download host $GDB_FULLPATH $xgdb] - set result [selftest_setup $file $function] - if {$result == 0} then { - set result [uplevel $body] + # When debugging GDB with GDB, some operations can take a relatively long + # time, especially if the build is non-optimized. Bump the timeout for the + # duration of the test. + with_timeout_factor 10 { + set result [selftest_setup $file $function] + if {$result == 0} then { + set result [uplevel $body] + } } gdb_exit