This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: PATCH: really close the extended-remote target if we lose the connection
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Date: Tue, 14 Oct 2008 23:07:48 +0100
- Subject: Re: PATCH: really close the extended-remote target if we lose the connection
- References: <200810142303.28790.pedro@codesourcery.com>
Sorry, I forgot an important detail in the explanations below. Hope the
below makes it clearer.
On Tuesday 14 October 2008 23:03:28, Pedro Alves wrote:
> Check out this difference between target remote, and target extended-remote:
>
> target remote:
>
> >./gdb /home/pedro/gdb/tests/threads32
> GNU gdb (GDB) 6.8.50.20081014-cvs
> [...]
> (gdb) tar remote :9999
> Remote debugging using :9999
> 0xf7fbb810 in ?? () from /lib/ld-linux.so.2
<insert "killall gdbserver" here>
> (gdb) info threads
> Remote connection closed
> (gdb) maint print target-stack
> The current target stack is:
> - exec (Local exec file)
> - None (None)
> (gdb) q
> [nothing]
>
> target extended-remote:
>
> >./gdb /home/pedro/gdb/tests/threads32
> GNU gdb (GDB) 6.8.50.20081014-cvs
> [...]
> (gdb) tar extended-remote :9999
> Remote debugging using :9999
> 0xf7f70810 in ?? () from /lib/ld-linux.so.2
> (gdb) c
> Continuing.
> [Switching to Thread 22227]
<insert "killall gdbserver" here>
> Remote connection closed
> (gdb) info threads
> putpkt: write failed: Broken pipe.
> (gdb)
>
> (gdb) maint print target-stack
> The current target stack is:
> - extended-remote (Extended remote serial target in gdb-specific protocol)
> - exec (Local exec file)
> - None (None)
> (gdb)
>
> (gdb) q
> The program is running. Quit anyway (and kill it)? (y or n) y
> Quitting: putpkt: write failed: Broken pipe.
>
> The issue is again the mixup of "target" as in
> 'interface'/'debug api'/'connection to system', vs "target" as in "inferior".
>
> In the remote target, a target_mourn_inferior unpushes the target_ops,
> while in the extended-remote target, it doesn't, leaving the user with
> a useless broken connection.
>
> The attached patch makes the extended-remote behave the same as the
> remote target. Considering an extended-remote connection debugging
> multi-processes seems to make it clearer that target_mourn_inferior
> isn't the right call here, me thinks.
>
> There are cases in async mode that when the connection was broken,
> we'd leave the SIGINT signal handler set to handle_remote_sigint or
> handle_remote_sigint_twice, although we had already poped the target,
> which would result in later crashes. I'm also making sure in remote_close
> that that doesn't happen.
>
> Any objections to this?
>
> No regressions on x86_64-unknown-linux-gnu (sync/async).
>
--
Pedro Alves