From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9592 invoked by alias); 11 Apr 2009 15:03:19 -0000 Received: (qmail 9582 invoked by uid 22791); 11 Apr 2009 15:03:18 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 11 Apr 2009 15:03:13 +0000 Received: (qmail 6957 invoked from network); 11 Apr 2009 15:03:11 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 11 Apr 2009 15:03:11 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFA] Don't kill inferior if there's a typo in the specified port. Date: Sat, 11 Apr 2009 15:03:00 -0000 User-Agent: KMail/1.9.10 Cc: Doug Evans References: <20090410231814.40469846AB@localhost> In-Reply-To: <20090410231814.40469846AB@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904111604.05252.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: 2009-04/txt/msg00207.txt.bz2 On Saturday 11 April 2009 00:18:14, Doug Evans wrote: > Hi. > > If there's a typo in the port gdbserver will kill the inferior. To be clear to everyone else following this at home, this is for "gdbserver --attach :badport PID", because the startup sequence is, 1) create or attach to inferior 2) open socket and wait for GDB connection So, if #2 fails, we have to unwind 1. Previously, we simply killed the inferior. That's bad when we have just attached to to a running process, not so bad if we have created a new inferior. > This fixes that by calling detach_or_kill_inferior_callback > instead of kill_inferior_callback. I think this makes sense. Even if we change the startup sequence to: 1) open and bind listen socket. 2) create/attach inferior 3) wait for GDB connection (`accept'). 4) go debug ... which would also fix your problem, between #3 and #4, an error can happen (although very rare), so we should detach from any attachee from point #2. The only thing that crosses my mind that could be strange, is that if we detached from an inferior due to a gdbserver error/fatal exit, while breakpoints are still installed, there's a risk that the inferior will trip on them much later, causing inferior SIGTRAP kamikaze. By killing the inferior immediately, the cause/effect was very evident. :-) There's no best behavior to chose, tough --- it's a compromise. I assume gdbserver will be gaining Z0 (memory breakpoints) support in the near future, which will make this point mostly moot. Plus, as you found out yesterday, we're already broken, in the case of something failing while debugging, and we error out while reopening the connection --- meaning that this is all theory that won't happen much in practice. All this giberish to say I'm all for detaching instead of killing. :-) > It also moves the status message to the callback; > it's only called when exiting gdb (and if that changes one can split > the function into silent/verbose versions). > An alternative is something like this: > > - fprintf (stderr, "Killing all inferiors\n"); > + fprintf (stderr, "Detaching or killing all inferiors\n"); > > but will that be confusing? Perhaps: "Detaching from inferiors we had attached to, and killing all others\n" dunno, don't want to start a bikeshed-ish discussion on that. > OTOH, if gdbserver ever gets used with 10's or 100's of processes, > exiting with one line per process may be a bit much. > OTOOH, the user might like to know what got detached and what got killed. > I don't know, but I can change the patch to do whatever y'all prefer. Yeah. If this is a real problem, then we could output something like, Killing process(es) PID1, PID2, PID3, PID4, PIDnn. Detaching process(es) PID1, PID2, PID3, PID4, PIDnn. This should mitigate the problem, although if you're really attached to 100's of processes, it will still print a lot. The other thing that crossed my mind was that if you had a bunch of processes, the real error message that let to gdbserver bailing out would be buried in the output many lines before all those "Killing/detaching process X". The only version that doesn't have this problem is the one that doesn't include any detail, like the first option. Anyway, I've no real inclination for any of these possible outputs. > Ok to check in? This is fine with me. Let's give it a few days in case Daniel or others want to comment. Thanks for documenting detach_or_kill_inferior_callback, btw ;-). -- Pedro Alves