[gdb/testsuite] Fix target_supports_scheduler_locking raciness

When calling gdb_start_cmd, it's the caller's responsibility to wait for gdb
to return to the prompt.  In target_supports_scheduler_locking, that's not the
case, and consequently, target_supports_scheduler_locking fails spuriously.

Fix by using runto_main instead.

Build and reg-tested on x86_64-linux.

2018-10-09  Tom de Vries  <tdevries@suse.de>

	* lib/gdb.exp (target_supports_scheduler_locking): Replace gdb_start_cmd
	with runto_main.

diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog
index d35abb5..c627578 100644 (file)
--- a/gdb/testsuite/ChangeLog
+++ b/gdb/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2018-10-09  Tom de Vries  <tdevries@suse.de>
+
+       * lib/gdb.exp (target_supports_scheduler_locking): Replace gdb_start_cmd
+       with runto_main.
+
 2018-10-08  Weimin Pan  <weimin.pan@oracle.com>
 
        PR c++/16841

diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index e91a3c8..2d197d9 100644 (file)
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -5971,7 +5971,9 @@ gdb_caching_proc target_supports_scheduler_locking {
     }
 
     clean_restart $obj
-    gdb_start_cmd
+    if ![runto_main] {
+        return 0
+    }
 
     set supports_schedule_locking -1
     set current_schedule_locking_mode ""