mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2024-11-28 20:43:45 +08:00
[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.
This commit is contained in:
parent
04fd5eed91
commit
58bbcd02de
@ -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
|
||||
|
@ -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 ""
|
||||
|
Loading…
Reference in New Issue
Block a user