From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80677 invoked by alias); 11 Sep 2018 11:27:49 -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 80668 invoked by uid 89); 11 Sep 2018 11:27:48 -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=H*M:d265 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; Tue, 11 Sep 2018 11:27:47 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D4BFE40216E7; Tue, 11 Sep 2018 11:27:45 +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 2D2FA63F41; Tue, 11 Sep 2018 11:27:45 +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> Cc: gdb-patches@sourceware.org, Jerome Guitton From: Pedro Alves Message-ID: <15fd4c1d-d265-073d-a4d8-14de3d607a44@redhat.com> Date: Tue, 11 Sep 2018 11:27: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: <20180911110417.GB3379@adacore.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-09/txt/msg00326.txt.bz2 On 09/11/2018 12:04 PM, Joel Brobecker wrote: > Hi Pedro, > >> It seems to me we can take a better approach here, that eliminates >> this particular problem not just for PikeOS, but for all other cases >> of random RTOS's. >> >> That is, you should be able to make your stub tell GDB that it >> can or can't hardware single step, and then GDB adjusts itself. > > 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. IWBN to fix the infrastructure, so that the next time a similar patch comes in we could just "no, fix your stub". :-) Thanks, Pedro Alves