Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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.
- Loading branch information