From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11524 invoked by alias); 13 Nov 2014 18:33:17 -0000 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 Received: (qmail 11511 invoked by uid 89); 13 Nov 2014 18:33:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 13 Nov 2014 18:33:08 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sADIX6kZ004562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 13 Nov 2014 13:33:06 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sADIX4fw021434; Thu, 13 Nov 2014 13:33:05 -0500 Message-ID: <5464F960.1020900@redhat.com> Date: Thu, 13 Nov 2014 18:33:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: "Breazeal, Don" , gdb-patches@sourceware.org Subject: Re: [PATCH 04/16 v3] Determine supported extended-remote features References: <1408580964-27916-1-git-send-email-donb@codesourcery.com> <1414798134-11536-2-git-send-email-donb@codesourcery.com> <5464AB33.8090903@redhat.com> <5464F854.1050906@codesourcery.com> In-Reply-To: <5464F854.1050906@codesourcery.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-11/txt/msg00274.txt.bz2 On 11/13/2014 06:28 PM, Breazeal, Don wrote: > On 11/13/2014 4:59 AM, Pedro Alves wrote: >> On 10/31/2014 11:28 PM, Don Breazeal wrote: >>> This patch implements a mechanism for GDB to determine what >>> extended-mode features are enabled in gdbserver. This is >>> a preparatory patch for extended-remote fork and exec event >>> support. >>> >>> Several new features are included in the potential response to >>> the qSupported packet, denoting fork, vfork, and exec events. >>> and exec events. Note that vfork_done events are not represented >>> here, because if vfork events are supported, gdbserver will fake >>> up a vfork_done event for GDB even if the target doesn't provide >>> direct support for vfork_done. >>> >>> A number of changes were required to make this work: >>> >>> 1) Sending the "!" (use extended protocol) packet before sending the >>> qSupported packet so that gdbserver knows it is in extended mode >>> when responding to qSupported. Previously qSupported was the >>> first packet sent. >> >> I don't think we should do this. What's wrong with always >> reporting support for the feature ? >> >> If GDB doesn't want them with "target remote", then it won't use >> them. >> >> If the server needs to know whether GDB supports or wants >> the feature before activating it, then GDB's qSupported query >> should indicate it. See the "multiprocess+" feature. >> >> As I mentioned before, I'd rather have fewer differences between >> "remote" and "extended-remote", not more. > Given your comment on patch 6 saying that there isn't any > reason not to support follow fork in remote as well as > extended-remote, the problem I was solving goes away. > > The problem I thought I had was that if there was no > agreement between GDB and gdbserver on whether the > features were supported, then gdbserver would send > events to GDB that it wasn't expecting in remote mode, > and handling those looked problematic. Yeah, but that's a problem that has to be handled when new gdbserver is connected to old gdb anyway, even in extended-remote mode. > Those bad assumptions get me every time. Sorry about that. :-/ I'm testing a fix for the stale-threads issue, that I think we can just go ahead and install, and I have a few other fixes to send you. Thanks, Pedro Alves