This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[PATCH, remote] Handle 'k' packet errors gracefully
- From: Luis Machado <lgustavo at codesourcery dot com>
- To: "'gdb-patches at sourceware dot org'" <gdb-patches at sourceware dot org>
- Date: Mon, 22 Apr 2013 16:32:28 +0200
- Subject: [PATCH, remote] Handle 'k' packet errors gracefully
- Reply-to: lgustavo at codesourcery dot com
Hi,
This is not a real problem with gdbserver, but other types of remote
targets (other stubs, QEMU etc) may cut the connection abruptly since
they are not required to reply to a 'k' (Kill) packet sent from GDB.
The following patch addresses any issues arising from such scenario,
which leads to a GDB internal error due to an attempt to pop the target
more than once. With the patch, this failure is handled gracefully.
As the ChangeLog suggests, i'm sending this on behalf of its original
authors.
Luis
2013-04-22 Pedro Alves <pedro@codesourcery.com>
Maciej W. Rozycki <macro@codesourcery.com>
gdb/
* remote.c (remote_kill): Handle errors from the kill packet
gracefully.
Index: gdb/remote.c
===================================================================
--- gdb.orig/remote.c 2013-04-22 14:13:25.512124202 +0200
+++ gdb/remote.c 2013-04-22 14:13:39.744123949 +0200
@@ -7714,12 +7714,36 @@ putpkt_for_catch_errors (void *arg)
static void
remote_kill (struct target_ops *ops)
{
- /* Use catch_errors so the user can quit from gdb even when we
+ struct gdb_exception ex;
+
+ /* Catch errors so the user can quit from gdb even when we
aren't on speaking terms with the remote system. */
- catch_errors (putpkt_for_catch_errors, "k", "", RETURN_MASK_ERROR);
+ TRY_CATCH (ex, RETURN_MASK_ERROR)
+ {
+ putpkt ("k");
+ }
+ if (ex.reason < 0)
+ {
+ if (remote_desc == NULL)
+ {
+ /* If we got an (EOF) error that caused the target
+ to go away, then we're done, that's what we wanted.
+ "k" is susceptible to cause a premature EOF, given
+ that the remote server isn't actually required to
+ reply to "k", and it can happen that it doesn't
+ even get to reply ACK to the "k". */
+ return;
+ }
+
+ /* Otherwise, something went wrong. We didn't actually kill
+ the target. Just propagate the exception, and let the
+ user or higher layers decide what to do. */
+ throw_exception (ex);
+ }
- /* Don't wait for it to die. I'm not really sure it matters whether
- we do or not. For the existing stubs, kill is a noop. */
+ /* We've killed the remote end, we get to mourn it. Since this is
+ target remote, single-process, mourning the inferior also
+ unpushes remote_ops. */
target_mourn_inferior ();
}