From 58bbcd02dee8ba018b97706c068ed8ed7afac15d Mon Sep 17 00:00:00 2001 From: Tom de Vries Date: Thu, 4 Oct 2018 14:10:39 +0200 Subject: [PATCH] [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 * lib/gdb.exp (target_supports_scheduler_locking): Replace gdb_start_cmd with runto_main. --- gdb/testsuite/ChangeLog | 5 +++++ gdb/testsuite/lib/gdb.exp | 4 +++- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog index d35abb5..c627578 100644 --- a/gdb/testsuite/ChangeLog +++ b/gdb/testsuite/ChangeLog @@ -1,3 +1,8 @@ +2018-10-09 Tom de Vries + + * lib/gdb.exp (target_supports_scheduler_locking): Replace gdb_start_cmd + with runto_main. + 2018-10-08 Weimin Pan PR c++/16841 diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index e91a3c8..2d197d9 100644 --- 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 "" -- 2.7.4