Re: RFC: skip_inline_frames failed assertion resuming from breakpoint on LynxOS

[Pedro Alves <palves@redhat.com>]

On 12/15/2014 02:58 PM, Joel Brobecker wrote:

>> GDB nowadays sends a single vCont packet that both steps thread A,
>> continues thread B with a signal and continues all other threads with
>> no signal (previously in some cases it'd just lose control of the
>> inferior, or deliver the signal to the wrong thread).  Something like:
>>
>>   vCont;s:A;C SIG:B;c
> [...]
>> Couldn't you iterate over the threads, and use PTRACE_STEP_ONE
>> for the stepped threads, and PTRACE_CONT_ONE for the others,
>> instead of PTRACE_CONT ?  For the case above, lynx_resume would
>> end up issuing:
>>
>>  PTRACE_STEP_ONE, thread A, sig 0
>>  PTRACE_CONT_ONE, thread B, sig SIG
>>  PTRACE_CONT_ONE, thread C, sig 0
>>  PTRACE_CONT_ONE, thread D, sig 0
> 
> Interesting. Do you mean sending those requests without waiting
> for the inferior to stop?

Yes.  This is what we do e.g., on Linux.  It just sounds like
Lynx's PTRACE_CONT_ONE is like Linux's PTRACE_CONT.  Linux has
no equivalent of Lynx's PTRACE_CONT (resume all threads with
a single request).

> I'd have to verify that it's possible
> to send ptrace requests while the inferior is "in flight", but
> wouldn't you then have possible race conditions?

Not sure what sort of race conditions you mean, but keep in mind
that I'm pretty clueless about Lynx.  :-)

Thanks,
Pedro Alves