From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15284 invoked by alias); 4 Mar 2009 19:18:14 -0000 Received: (qmail 15275 invoked by uid 22791); 4 Mar 2009 19:18:13 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Mar 2009 19:18:06 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 02DB02BAACA; Wed, 4 Mar 2009 14:18:08 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 89-OuEJ7tq3R; Wed, 4 Mar 2009 14:18:07 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id B88752BAB8A; Wed, 4 Mar 2009 14:18:05 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 59B56E7ACD; Wed, 4 Mar 2009 11:18:00 -0800 (PST) Date: Wed, 04 Mar 2009 19:18:00 -0000 From: Joel Brobecker To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [remote/rfc] Let GDB know if a remote server originally attached to a process. Message-ID: <20090304191800.GB3729@adacore.com> References: <200903040117.32166.pedro@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903040117.32166.pedro@codesourcery.com> User-Agent: Mutt/1.4.2.2i 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-03/txt/msg00054.txt.bz2 > There's an obvious workaround for this (detach explicitly, then quit GDB), > but this ought to be changed for consistency (*). I agree. Not only that, but differences like these can be very annoying when setting up automated testing. You write a test script that expects one thing because that's what happens in the native case, then all of a sudden, you have an exception when using gdbserver... > This is simple enough --- the patch is smaller than this > whole description of it :-) I was considering if we want to > generalize a mechanism for this or not, say similar to target > descriptions, but I don't have any other use case for such a thing. I'm not very familiar with the remote protocol, but I don't see much benefit in generalizing this approach. Perhaps you'd like to expand, but I'm happy with the simple approach you took. The patch looks OK to me too. There are one or two new functions that are undocumented, and we've been bugging contributors about this, so it'd be nice to have a short description preceding them. Other than that, no comment. -- Joel