Re: [PATCH] gdb/testsuite/gdb.rocm: Fix incorrect use of continue N in multi-inferior-gpu.exp

Lancelot SIX
2023-10-18T08:33:28Z

On 17/10/2023 15:48, Simon Marchi wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>
>
> On 10/17/23 10:41, Lancelot SIX wrote:
>>
>>> On 10/17/23 07:16, Lancelot Six wrote:
>>>> The gdb.rocm/multi-inferior-gpu.exp testcase uses a "continue $thread"
>>>> command, but this is incorrect. If "continue" is given an argument, it
>>>> sets the ignore count of the breakpoint the thread stopped at.
>>>>
>>>> For this testcase it does not really matter since the breakpoint is not
>>>> meant to be hit anymore, so whatever the ignore count is won't influence
>>>> the outcome of the test. It is worth fixing nevertheless.
>>>>
>>>> While at changing it, switch to using "continue&" to consume the GDB
>>>> prompt right away. This makes the following pattern matching more
>>>> reliable.
>>>
>>> I don't understand the "more reliable" part, can you explain?
>>>
>>> Simon
>>
>> There will be a "(gdb) " prompt appearing at some point after a "continue", but in non-stop we don't really control when it appears (if I understand correctly). It seems that other non-stop tests use the "&" variant and consume the prompt immediately.
>>
>> With this, before the next command is issued, we know that 1) we got a prompt and 2) we have seen the process we just released finish.
>>
>> Overall, I am mostly trying to follow patterns I caught in other non-stop tests.
>
> Ah, I missed that we were in non-stop.
>
> If we run a single thread at a time, I think it will be reliable to use
> the sync variant of continue. Using the async variant is useful when
> you resume multiple threads and expect multiple events (like breakpoint
> hits) which can happen in any order. At least that's my understanding.
>
> Simon

OK, if you find it is overdoing it, I'll revert this part of the patch
and submit a V2 shortly.

Thanks,
Lancelot.