process-dies-while-detaching.exp: Exit early if GDB misses sync breakpoint
authorThiago Jung Bauermann <thiago.bauermann@linaro.org>
Thu, 28 Sep 2023 11:17:54 +0000 (08:17 -0300)
committerThiago Jung Bauermann <thiago.bauermann@linaro.org>
Fri, 6 Oct 2023 20:36:42 +0000 (17:36 -0300)
I'm seeing a lot of variability in the failures of
gdb.threads/process-dies-while-detaching.exp on aarch64-linux.  On this
platform, a problem yet to be investigated causes GDB to miss the _exit
breakpoint.  What happens next is random because after missing that
breakpoint, GDB is out of sync with the inferior.  This causes the tests
following that point in the testcase to fail in a random way.

In this scenario it's better to exit the testcase early to avoid random
results in the testsuite.

We are relying on gdb_continue_to_breakpoint to return the result of
gdb_test_multiple.  This is already the case because in Tcl the return
value of a function is the return value of the last command it runs.  But
change gdb_continue_to_breakpoint to explicitly return this value, to make
it clear this is the intended behaviour.

Tested on aarch64-linux.

Tested-By: Guinevere Larsen <blarsen@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
gdb/testsuite/gdb.threads/process-dies-while-detaching.exp
gdb/testsuite/lib/gdb.exp

index bbbe82df30cdd4e5acf79556d08bac10e217d939..c7d43d7dddccccd187e8572ed95b44a43870c9ee 100644 (file)
@@ -127,7 +127,7 @@ proc detach_and_expect_exit {inf_output_re test} {
 
 proc continue_to_exit_bp {} {
     gdb_breakpoint "_exit" temporary
-    gdb_continue_to_breakpoint "_exit" ".*_exit.*"
+    return [gdb_continue_to_breakpoint "_exit" ".*_exit.*"]
 }
 
 # If testing single-process, simply detach from the process.
@@ -226,7 +226,7 @@ proc test_detach {multi_process cmd} {
        }
 
        # Run to _exit in the child.
-       continue_to_exit_bp
+       return_if_fail [continue_to_exit_bp]
 
        do_detach $multi_process $cmd "normal"
     }
@@ -265,13 +265,13 @@ proc test_detach_watch {wp multi_process cmd} {
            # them out, and handle the case of the thread disappearing
            # while doing that (on targets that need to detach from each
            # thread individually).
-           continue_to_exit_bp
+           return_if_fail [continue_to_exit_bp]
        } else {
            # Force software watchpoints.
            gdb_test_no_output "set can-use-hw-watchpoints 0"
 
            # As above, but flip order, other wise things take too long.
-           continue_to_exit_bp
+           return_if_fail [continue_to_exit_bp]
            gdb_test "watch globalvar" "Watchpoint $decimal: globalvar"
 
            if { $multi_process == 0 && $cmd == "continue" } {
@@ -304,7 +304,7 @@ proc test_detach_killed_outside {multi_process cmd} {
        }
 
        # Run to _exit in the child.
-       continue_to_exit_bp
+       return_if_fail [continue_to_exit_bp]
 
        set childpid [get_integer_valueof "mypid" -1]
        if { $childpid == -1 } {
index 3cad4f7cb4b26ed6dbcc8036ae24875bce92280f..0a908e0af0f84bd8cec7f5c514f02120248e6176 100644 (file)
@@ -822,14 +822,14 @@ proc gdb_continue_to_breakpoint {name {location_pattern .*}} {
     set full_name "continue to breakpoint: $name"
 
     set kfail_pattern "Process record does not support instruction 0xfae64 at.*"
-    gdb_test_multiple "continue" $full_name {
+    return [gdb_test_multiple "continue" $full_name {
        -re "(?:Breakpoint|Temporary breakpoint) .* (at|in) $location_pattern\r\n$gdb_prompt $" {
            pass $full_name
        }
        -re "(?:$kfail_pattern)\r\n$gdb_prompt $" {
            kfail "gdb/25038" $full_name
        }
-    }
+    }]
 }