From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98403 invoked by alias); 6 Apr 2016 14:31:12 -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 98384 invoked by uid 89); 6 Apr 2016 14:31:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1461 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; Wed, 06 Apr 2016 14:31:10 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0D1342FA for ; Wed, 6 Apr 2016 14:31:09 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u36EV7Dp011191; Wed, 6 Apr 2016 10:31:08 -0400 Subject: Re: [patchv4] Workaround gdbserver<7.7 for setfs To: Jan Kratochvil References: <20160319201842.GA16540@host1.jankratochvil.net> <56F13963.9040204@redhat.com> <20160322131604.GA24312@host1.jankratochvil.net> <56F14F1E.5010606@redhat.com> <20160323211547.GA17400@host1.jankratochvil.net> <20160324220933.GA27445@host1.jankratochvil.net> <20160324223241.GB2548@host1.jankratochvil.net> <56FBDFE7.90203@redhat.com> <20160404211406.GA32241@host1.jankratochvil.net> <5703E7FF.6060304@redhat.com> <20160406134911.GA30545@host1.jankratochvil.net> Cc: gdb-patches@sourceware.org, Gary Benson From: Pedro Alves Message-ID: <57051DAB.7000008@redhat.com> Date: Wed, 06 Apr 2016 14:31:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <20160406134911.GA30545@host1.jankratochvil.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-04/txt/msg00125.txt.bz2 On 04/06/2016 02:49 PM, Jan Kratochvil wrote: >> > Try qMustReplyEmpty or something like that instead. > With these requirements on this workaround I have followed the gdbserver-7.6 > sources and the bug was in function handle_notif_ack which is called only from > handle_v_requests, therefore for any packets /^v/. Ah. > OK to check in this one? OK with a change. > diff --git a/gdb/remote.c b/gdb/remote.c > index 5c407b6..a88f4cd 100644 > --- a/gdb/remote.c > +++ b/gdb/remote.c > @@ -1496,6 +1496,15 @@ enum { > > static struct packet_config remote_protocol_packets[PACKET_MAX]; > > +/* gdbserver < 7.7 (before its fix from 2013-12-11) did reply to any > + unknown 'v' packet with string "OK". "OK" gets interpreted by GDB > + as a reply to known packet. For packet "vFile:setfs:" it is an > + invalid reply and GDB would return error in > + remote_hostio_set_filesystem, making remote files access impossible. > + If this variable is non-zero it means the remote gdbserver is buggy > + and any not yet detected packets are assumed as unsupported. */ > +static int unknown_v_replies_ok; This comment looks great now, thanks. It helps the reader understand exactly what is being worked around, and it'll help us decide what to do in the future if this ever gets in the way. Please make this new variable a field of 'struct remote_state' instead of a global. OK with that change. Thanks, Pedro Alves