Testsuite: Remove race condition from mi-cmd-param-changed.exp
Commit Message
target_supports_scheduler_locking does not wait for the gdb
prompt after calling gdb_start_cmd.
Fix by replacing with runto_main.
This removes the racy behaviour of mi-cmd-param-changed.exp.
gdb/testsuite/ChangeLog:
2018-10-09 Alan Hayward <alan.hayward@arm.com>
* lib/gdb.exp (target_supports_scheduler_locking): Call runto_main.
---
gdb/testsuite/lib/gdb.exp | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Comments
On 10/09/2018 01:44 PM, Alan Hayward wrote:
> target_supports_scheduler_locking does not wait for the gdb
> prompt after calling gdb_start_cmd.
>
> Fix by replacing with runto_main.
>
> This removes the racy behaviour of mi-cmd-param-changed.exp.
>
> gdb/testsuite/ChangeLog:
>
> 2018-10-09 Alan Hayward <alan.hayward@arm.com>
>
> * lib/gdb.exp (target_supports_scheduler_locking): Call runto_main.
Tom de Vries had already submitted a patch for this, but it
hadn't been reviewed yet. I've approved Tom's now. Sorry
about the duplicated work.
Thanks,
Pedro Alves
> On 9 Oct 2018, at 14:00, Pedro Alves <palves@redhat.com> wrote:
>
> On 10/09/2018 01:44 PM, Alan Hayward wrote:
>> target_supports_scheduler_locking does not wait for the gdb
>> prompt after calling gdb_start_cmd.
>>
>> Fix by replacing with runto_main.
>>
>> This removes the racy behaviour of mi-cmd-param-changed.exp.
>>
>> gdb/testsuite/ChangeLog:
>>
>> 2018-10-09 Alan Hayward <alan.hayward@arm.com>
>>
>> * lib/gdb.exp (target_supports_scheduler_locking): Call runto_main.
>
> Tom de Vries had already submitted a patch for this, but it
> hadn't been reviewed yet. I've approved Tom's now. Sorry
> about the duplicated work.
>
No probs, glad it got fixed.
Alan.
@@ -5957,7 +5957,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 ""