From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95474 invoked by alias); 9 Oct 2018 18:30:46 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 88824 invoked by uid 89); 9 Oct 2018 18:30:34 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=stepping, qsupported, historical, qSupported 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 ESMTP; Tue, 09 Oct 2018 18:30:32 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CB7CA30832D8; Tue, 9 Oct 2018 18:30:30 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3130F747BF; Tue, 9 Oct 2018 18:30:30 +0000 (UTC) Subject: Re: gdb ignoring vCont supported commands To: Bill Morgan , gdb@sourceware.org References: From: Pedro Alves Message-ID: <0eeb55ca-d4e1-4db4-e601-74ca7e1151e2@redhat.com> Date: Tue, 09 Oct 2018 18:30:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-10/txt/msg00010.txt.bz2 On 10/09/2018 02:42 PM, Bill Morgan wrote: > I tell gdb that I support only vCont c and C, so it sends me s. Why is it > sending s when I don't support that? > > (gdb) s > Sending packet: > $QPassSignals:e;10;14;17;1a;1b;1c;21;24;25;2c;4c;97;#0a...Ack > Packet received: OK > Sending packet: $vCont?#49...Ack > Packet received: vCont;c;C > Packet vCont (verbose-resume) is supported > Sending packet: $vCont;s:13;c#f4...Ack > Packet received: E01 > warning: Remote failure reply: E01 That's historical behavior, and GDB cannot change it, unfortunately. But the good news is that in more recent GDBs there is a protocol extension to tell GDB to trust the set of reported supported vCont actions. Copying what I said here: https://sourceware.org/ml/gdb-patches/2018-09/msg00359.html ~~~~~~~~~~~~~~~~~~~~~~~~ GDB can't trust "vCont;c;C" alone, because for a long while GDBserver would send "vCont;c;s;C;S" even if the target did not support hardware stepping. So what a stub needs to do is: Return "vCont;c;C" to "vCont?" _AND_ include "vContSupported" in the reported "qSupported" features. The latter tells GDB to trust that the actions included in "vCont?" are really the supported ones. (I wish we had implemented this a little bit differently, but that ship has sailed, and although a bit cumbersome, it works.) ~~~~~~~~~~~~~~~~~~~~~~~~ Thanks, Pedro Alves