OpenE2K
/
binutils-gdb
12
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

[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:
Tom de Vries 2018-10-04 14:10:39 +02:00
parent 04fd5eed91
commit 58bbcd02de
2 changed files with 8 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
gdb/testsuite/ChangeLog
View File

@ -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

4
gdb/testsuite/lib/gdb.exp
View File

@ -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 ""