Re: [PATCH] Fix fail in gdb.base/interrupt-noterm.exp

[Pedro Alves <palves at redhat dot com>]

On 01/22/2016 05:14 PM, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
> 
>> Can you expand the rationale some more?
>>
>> E.g., why is this not a gdbserver bug?  Instintively I'd say it is.
> 
> The interaction between GDB and GDBserver is like this,
> 
>   1. GDB sends vCont;c and doesn't wait for the stop reply because
>   "continue &" is background command,
>   2. GDBserver receives vCont;c, enables the async i/o (by
>   enable_async_io) and resumes the inferior.
>   3. GDB sends interrupt packet,
> 
> #1 happens before #2 and #3, but the order of #2 and #3 is not
> determined.  If #2 happens before #3, it is fine, otherwise, the
> GDBserver doesn't know the interrupt from GDB.

If 1. is followed by 3., then the \\003 is always read by gdb
after the vCont;c.  We call enable_async_io before reaching
mywait.  Since we're in all-stop, that means we'll block
inside mywait -> waitpid, all the while \\003 is already available to
read in the socket.  Since we're blocked in waitpid, we won't see
the \\003 until after the next time the program happens to stop.

Agree?

It still seems to me like a gdbserver bug.

I think that after calling enable_async_io, we need to check whether
input is already pending from GDB, and if so, process it immediately -- we
know the only input coming from GDB at this point is a \\003.  IOW, I think
we need to call input_interrupt after calling enable_async_io.  input_interrupt
already uses select before reading, so it handles the case of there
being no input available without blocking.

However, we need to be careful, because a SIGIO can race with calling
input_interrupt from mainline code...

Thanks,
Pedro Alves