From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8016 invoked by alias); 13 Nov 2014 18:28:50 -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 7997 invoked by uid 89); 13 Nov 2014 18:28:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Nov 2014 18:28:47 +0000 Received: from svr-orw-fem-03.mgc.mentorg.com ([147.34.97.39]) by relay1.mentorg.com with esmtp id 1Xoz8O-0005zl-Fr from Don_Breazeal@mentor.com ; Thu, 13 Nov 2014 10:28:44 -0800 Received: from [172.30.1.21] (147.34.91.1) by SVR-ORW-FEM-03.mgc.mentorg.com (147.34.97.39) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 13 Nov 2014 10:28:43 -0800 Message-ID: <5464F854.1050906@codesourcery.com> Date: Thu, 13 Nov 2014 18:28:00 -0000 From: "Breazeal, Don" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Pedro Alves , 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> In-Reply-To: <5464AB33.8090903@redhat.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-11/txt/msg00273.txt.bz2 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. > > Thanks, > Pedro Alves > 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. Those bad assumptions get me every time. Thanks, --Don