This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Include putpkt in TRY_CATCH. PR gdb/51275
- From: Gareth McMullin <gareth at blacksphere dot co dot nz>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 21 Mar 2013 16:49:49 +1300
- Subject: Re: Include putpkt in TRY_CATCH. PR gdb/51275
- References: <CAL8qUbrD=fgMP7nE0O8tX=AXifUpQXas25o_4SfK4p79rfoUpw at mail dot gmail dot com> <CAL8qUbqjtBKJFJZ6dPS78Zh8Eb3b33U9JXTmn1pS3Le93xt7Rw at mail dot gmail dot com> <20130320170829 dot GA29887 at host2 dot jankratochvil dot net> <CAL8qUbrTf_GPBRwAjrnbhuqgM+eBA=aUNdAAmwN-Bp8TGCLe-A at mail dot gmail dot com>
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