This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Fix gdbserver queued packet handling
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Cc: Doug Evans <dje at google dot com>
- Date: Fri, 30 Apr 2010 18:55:12 +0100
- Subject: Re: [RFA] Fix gdbserver queued packet handling
- References: <20100430171731.5600984398@ruffy.mtv.corp.google.com>
On Friday 30 April 2010 18:17:31, Doug Evans wrote:
> 2010-04-30 Doug Evans <dje@google.com>
>
> * server.h (queue_file_read_event): Declare.
> (reschedule_remote): Declare.
> * event-loop.c (queue_file_read_event): New function.
> * remote-utils.c (reschedule_remote): New function.
> (readchar_buf, readchar_bufcnt, readchar_bufp): New static globals,
> moved out of readchar.
> * server.c (handle_serial_event): Call reschedule_remote.
This looks good, thanks. Please apply.
> @@ -3009,6 +3009,10 @@ handle_serial_event (int err, gdb_client
> Important in the non-stop mode asynchronous protocol. */
> set_desired_inferior (1);
>
> + /* Give the packet reader a chance to schedule more work before
> + we go to sleep. */
> + reschedule_remote ();
> +
This seems to break the abstraction a bit. GDB attempts
a reschedule on every `readchar', and avoids unnecessary calls
into the event loop by maintaining a state machine, so
everything is nicelly hidden within the serial handling code.
But I'm fine with this simpler mechanism. I can't think
of any reads from the socket outside of handle_serial_event;
we'd be still in trouble this way if there were. In non-stop, we
push stop notifications to gdb when handling target events, but
asynchronous RSP notifications are a special kind of packet
that is never acked, even if no-ack is off, so not even those
cause reads that could cause data being pulled to the buffer.
--
Pedro Alves