aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2023-06-15 10:31:39 +0100
committerAndrew Burgess <aburgess@redhat.com>2023-07-17 09:45:19 +0100
commit1e12f6358cf4ed7386f61b8bda60a45209794066 (patch)
tree5f0228363f0e0c0d1d4bf7eace88d60e23579005
parent8193fa9cbe1a6cdb2cb41cedb835de33a1c755e3 (diff)
downloadgdb-1e12f6358cf4ed7386f61b8bda60a45209794066.zip
gdb-1e12f6358cf4ed7386f61b8bda60a45209794066.tar.gz
gdb-1e12f6358cf4ed7386f61b8bda60a45209794066.tar.bz2
gdb: catch more errors in gdb.base/foll-vfork.exp
For *reasons* I was looking at gdb.base/foll-vfork.exp. This test script has a proc 'setup_gdb' that could (potentially) fail. The setup_gdb proc is called from many places and I, initially, didn't think that we were checking if setup_gdb had failed or not. My confusion was because I didn't understand what this tcl construct did: return -code return this will actually act as a return in the context of a proc's caller, effectively returning two levels of the call stack. Neat (I guess). So it turns out my worries were misplaced, everywhere setup_gdb is called, if setup_gdb fails then we will (magically) return. However, I did spot one place where we managed to confuse ourselves with our cleverness. In check_vfork_catchpoints, this proc is called to check that GDB is able to catch vforks or not. This proc is called early in the test script, and the intention is that, should this proc fail, we'll mark the whole test script as unsupported and then move onto the next test script. However, check_vfork_catchpoints also uses setup_gdb, and so, if that call to setup_gdb fails we'll end up returning immediately from check_vfork_catchpoints, and then continue with the test of _this_ test script, which is not correct. To fix this I see two choices, one is remove the use of 'return -code return' from setup_gdb, however, this would require every use of setup_gdb to then be placed inside: if { ![setup_gdb] } { return } Or, I can wrap the one call to setup_gdb in check_vfork_catchpoints and check its return code. I chose the second option as this is the smaller code change. There should be no change in what is tested after this commit.
-rw-r--r--gdb/testsuite/gdb.base/foll-vfork.exp10
1 files changed, 8 insertions, 2 deletions
diff --git a/gdb/testsuite/gdb.base/foll-vfork.exp b/gdb/testsuite/gdb.base/foll-vfork.exp
index 313afa0..bdceff0 100644
--- a/gdb/testsuite/gdb.base/foll-vfork.exp
+++ b/gdb/testsuite/gdb.base/foll-vfork.exp
@@ -70,9 +70,15 @@ proc setup_gdb {} {
proc check_vfork_catchpoints {} {
global gdb_prompt
- global has_vfork_catchpoints
- setup_gdb
+ # Because setup_gdb uses 'return -code return' which would return to
+ # our caller we need to wrap this call, spot when setup_gdb failed
+ # (with return code 2), and then issue our own 'return -code return'.
+ set code [catch {setup_gdb} string]
+ if { $code == 2 } {
+ unsupported "vfork catchpoints"
+ return -code return
+ }
# Verify that the system supports "catch vfork".
gdb_test "catch vfork" "Catchpoint \[0-9\]* \\(vfork\\)" "insert first vfork catchpoint"