From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109795 invoked by alias); 12 Sep 2018 13:22:57 -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 109671 invoked by uid 89); 12 Sep 2018 13:22:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=suspected, ack X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Sep 2018 13:22:54 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0925F40216EB; Wed, 12 Sep 2018 13:22:53 +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 50B832157F49; Wed, 12 Sep 2018 13:22:52 +0000 (UTC) Subject: Re: [RFA] arm-pikeos: software single step To: Joel Brobecker References: <1536592407-13448-1-git-send-email-brobecker@adacore.com> <808bd91f-3ad3-9a42-bc04-ac42835fceb9@redhat.com> <20180911110417.GB3379@adacore.com> <15fd4c1d-d265-073d-a4d8-14de3d607a44@redhat.com> <20180911205742.GB12573@adacore.com> Cc: gdb-patches@sourceware.org, Jerome Guitton From: Pedro Alves Message-ID: <9ff1cf95-0ec4-dd58-6445-4fd51730a7d8@redhat.com> Date: Wed, 12 Sep 2018 13:22: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: <20180911205742.GB12573@adacore.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-09/txt/msg00359.txt.bz2 On 09/11/2018 09:57 PM, Joel Brobecker wrote: > Hi again Pedro, > >>> Unfortunately, the problem is that we do not control the stub (muxa), >>> it is a tool that the vendor provides. >> >> Did you check whether it is already reporting the RSP packets as I >> had suggested? We wouldn't be adding new packets, but instead using >> some that are already defined. >> >> If the stub really needs modification, I'm not opposed to your patch >> as stop gap. Would there be any chance to forward the information to >> the sysgo folks, see if they're willing to tweak the stub? It should >> be a trivial change. > > So, here is what I could gather (full log at the end of this email [1]). > GDB sends the $qSupported packet, equiring about support... > > | Sending packet: $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df...Ack > > ... and the list returned is fairly small, as I suspected: > > | Packet received: qXfer:features:read+ > > After that, I don't see very much happening at the vCont level, > so fast-forward to the first "cont" command (after having inserted > a breakpoint), and we see some interesting stuff. In particular, > GDB asks the target what vCont support it provides, and here is > what we receive: > > | Sending packet: $vCont?#49...Ack > | Packet received: vCont;c;s;C;S > | Packet vCont (verbose-resume) is supported > > Hah! So, on the one end, the stub says stepping is supported > ('s' and 'S'), but on the other hand we were told that this > feature is not supported on ARM. > > So, if I understand correctly the current situation, we do have > one small infrastructure adjustment to do in GDB, but then once > done, if the stub on advertised support for "vCont;c;C", then > GDB would automatically be switching to software single step. > Do I understand correctly? Almost. 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.) > > If that's correct, I'll make sure AdaCore forwards the suggestion > to Sysgo. > > Thanks! Thanks, Pedro Alves