Re: evl: ptrace continue without hardware singlestepping support

Philippe Gerum <[email protected]> writes:

> Tobias Schaffner <[email protected]> writes:
>
>> Hi Philippe,
>>
>> the RISC-V port has an open issue regarding OOB synchronization of
>> threads in the EVL ptrace implementation, which leads to a deadlock
>> when running the ptrace-sync test.
>>
>> RISC-V currently does not support hardware-based single stepping, and
>> GDB’s behavior on `continue` with multiple threads is different.
>>
>> If hardware single stepping is available, GDB single-steps the hitter
>> with PTRACE_SINGLESTEP and continues the other threads with
>> PTRACE_CONT. All threads are continued and can pass the
>> evl_wait_event() barrier in handle_ptstop_event(). The hitter breaks
>> again and is finally continued.
>>
>> In contrast, if hardware single stepping is not available, GDB adds a
>> breakpoint to the next instruction, wakes only the hitter with
>> PTRACE_CONT, and waits for it to make its step before waking its
>> siblings. However, the hitter is not able to make its step because it
>> waits in the kernel for its siblings in evl_wait_event(), which are
>> not going to be woken by GDB until the hitter makes its step.
>>
>> The attached strace files show the behavior of GDB on both
>> architectures when continuing the breaking worker thread in
>> `ptrace.c`.
>>
>> Jan already pointed out that there may be a general problem with
>> expecting GDB to always continue all threads, and I think he is
>> right. Changing the scheduler-locking mode in All-Stop Mode [1], as
>> well as switching to Non-Stop Mode [2], should lead to similar issues.
>>
>
> Stop mode would be an issue if the synchronization fully happened on
> PTCONT, but the evl core requires threads to wait on the sync barrier

s/to wait on/to be awaited for/

-- 
Philippe.