diff options
author | Andrew Burgess <aburgess@redhat.com> | 2023-06-15 10:31:39 +0100 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2023-07-17 09:45:19 +0100 |
commit | 1e12f6358cf4ed7386f61b8bda60a45209794066 (patch) | |
tree | 5f0228363f0e0c0d1d4bf7eace88d60e23579005 | |
parent | 8193fa9cbe1a6cdb2cb41cedb835de33a1c755e3 (diff) | |
download | gdb-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.exp | 10 |
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" |