From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25423 invoked by alias); 13 Nov 2014 18:48:18 -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 25403 invoked by uid 89); 13 Nov 2014 18:48:17 -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:48:11 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sADIm895029106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 13 Nov 2014 13:48:08 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sADIm6eo012215; Thu, 13 Nov 2014 13:48:07 -0500 Message-ID: <5464FCE6.1080702@redhat.com> Date: Thu, 13 Nov 2014 18:48: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: <5464F854.1050906@codesourcery.com> <5464FA50.1000707@codesourcery.com> In-Reply-To: <5464FA50.1000707@codesourcery.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-11/txt/msg00276.txt.bz2 On 11/13/2014 06:37 PM, Breazeal, Don wrote: > 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. This change > should make things simpler as long as I don't run into > troubles with "remote". The only thing I'm imagining at the moment, is that in "remote" mode, gdbserver always disconnects after a "D" / detach packet, even if there are other processes to debug. But that seems silly anyway and we should probably fix it. As I mentioned, you'll need to make old GDB against new GDBserver work correctly, that is, make gdbserver not send these new events if debugging with old GDB, which is not expecting them. That can be handled by making GDB send a "fork-events+" in its own qSupported packet, so that GDBserver knows its talking to a new GDB. See how the "multiprocess+" feature is handled in both GDB and GDBserver. For a while, GDB didn't broadcast "multiprocess+" when connecting with "target remote". See: https://sourceware.org/ml/gdb-patches/2012-01/msg00490.html One of the reasons I wanted that on "remote" was exactly to make it possible to have fork events without caring for remote vs extended-remote. :-) If there are bigger problems, we can make GDB not broadcast the support with plain remote for starters. But I'd be curious to hear what the problems are. Thanks, Pedro Alves