Re: Include putpkt in TRY_CATCH. PR gdb/51275

[Gareth McMullin <gareth@blacksphere.co.nz>]

On Thu, Mar 21, 2013 at 1:41 PM, Gareth McMullin
<gareth@blacksphere.co.nz> wrote:
> On Thu, Mar 21, 2013 at 6:08 AM, Jan Kratochvil
> <jan.kratochvil@redhat.com> wrote:
>> I guess it should also fix it but I probably cannot not replicate your serial
>> stub conditions here.
>
> I tried to reproduce with GDB server, because I expected similar behaviour on
> a broken socket, but this actually works, on Linux, at least:
>
> (gdb) tar ext localhost:2000
> Remote debugging using localhost:2000
> (gdb) set debug remote 1
> ... gdbserver killed from another terminal ...
> (gdb) quit
> Sending packet: $qTStatus#49...Remote connection closed
> (gdb) quit
>
> The send(2) ultimately called by putpkt actually succeeds on the broken socket,
> while the write(2) used for Unix serial ports fails with EIO.  Changing
> ser_unix_write_prim to fake success on EIO doesn't solve the problem as the
> serial read doesn't distinguish between EOF and TIMEOUT.  I'll need to examine
> ser-unix.c in more detail to see exactly what's going on there.

Changing ser-unix.c to use ser_base_readchar and faking success on EIO in
ser_unix_write_prim fixes this for me.  There are warnings in the comments
about using user_base_readchar in ser-unix.c because of read returning no
data on timeout, but if I read it correctly, read won't be called unless select
found it ready to read.  The timeout is handled by select which works for me on
Linux/termios and seems like a better solution than using the termios VTIME
parameter.  It also appears that this is exactly what it would be doing if using
the SGTTY serial code too.  Is there a reason we would prefer to use VTIME
for the timeout rather than select when using the termio/termios interface?

Regards,
Gareth