From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19742 invoked by alias); 14 Oct 2008 22:08:05 -0000 Received: (qmail 19542 invoked by uid 22791); 14 Oct 2008 22:08:05 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 14 Oct 2008 22:07:29 +0000 Received: (qmail 12231 invoked from network); 14 Oct 2008 22:07:27 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 14 Oct 2008 22:07:27 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: PATCH: really close the extended-remote target if we lose the connection Date: Tue, 14 Oct 2008 22:08:00 -0000 User-Agent: KMail/1.9.9 References: <200810142303.28790.pedro@codesourcery.com> In-Reply-To: <200810142303.28790.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200810142307.48530.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-10/txt/msg00357.txt.bz2 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 > (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] > 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