From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13572 invoked by alias); 11 Sep 2018 09:08:17 -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 13556 invoked by uid 89); 11 Sep 2018 09:08:17 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.3 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=remote.c, remotec, UD:remote.c, remote_target 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 09:08:15 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B5561401DEAF; Tue, 11 Sep 2018 09:08:13 +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 0480510FFE6F; Tue, 11 Sep 2018 09:08:12 +0000 (UTC) Subject: Re: [RFA] arm-pikeos: software single step To: Joel Brobecker , gdb-patches@sourceware.org References: <1536592407-13448-1-git-send-email-brobecker@adacore.com> Cc: Jerome Guitton From: Pedro Alves Message-ID: <808bd91f-3ad3-9a42-bc04-ac42835fceb9@redhat.com> Date: Tue, 11 Sep 2018 09:08: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: <1536592407-13448-1-git-send-email-brobecker@adacore.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-09/txt/msg00312.txt.bz2 On 09/10/2018 04:13 PM, Joel Brobecker wrote: > From: Jerome Guitton > > Hello, > > On ARM, PikeOS does not support hardware single step, causing various > semi-random errors when trying to next/step over some user code. So > this patch changes this target to use software-single-step instead. > > The challenge is that, up to now, the PikeOS target was in all respects > identical to a baremetal target as far as GDB was concerned, meaning > we were using the baremetal osabi for this target too. This is no longer > possible, and we need to introduce a new OSABI variant. Unfortunately, > there isn't anything in the object file that would allow us to > differentiate between the two platforms. So we have to rely on a > heuristic instead, where we look for some known symbols that are > required in a PikeOS application (these symbols are expected to be > defined by the default linker script, and correspond to routines used > to allocate the application stack). It's unfortunate to have to introduce an OSABI for something that is a property of the target that doesn't effect anything when e.g., you're not connected yet. 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. We already have all the info we need, we're just not using it. See target_can_do_single_step and the remote.c implementation: int remote_target::can_do_single_step () { /* We can only tell whether target supports single step or not by supported s and S vCont actions if the stub supports vContSupported feature. If the stub doesn't support vContSupported feature, we have conservatively to think target doesn't supports single step. */ if (packet_support (PACKET_vContSupported) == PACKET_ENABLE) >From the manual: @item vContSupported This feature indicates whether @value{GDBN} wants to know the supported actions in the reply to @samp{vCont?} packet. @end table @item vCont? @cindex @samp{vCont?} packet Request a list of actions supported by the @samp{vCont} packet. So, if you make your stub indicate support for the "vContSupported" feature, and make sure the the reply to "vCont?" does not include the s/S features, then GDB knows the target does not support hardware single step. The only think missing then I think is moving the only call to target_can_do_single_step out of the arm-linux-tdep.c file: static std::vector arm_linux_software_single_step (struct regcache *regcache) { struct gdbarch *gdbarch = regcache->arch (); struct arm_get_next_pcs next_pcs_ctx; /* If the target does have hardware single step, GDB doesn't have to bother software single step. */ if (target_can_do_single_step () == 1) return {}; into somewhere more generic, around infrun.c:maybe_software_singlestep. Can you try that? Thanks, Pedro Alves > > gdb/ChangeLog (Jerome Guitton ): > > * arm-pikeos-tdep.c: New file. > * configure.tgt: Add arm-pikeos-tdep.o to the case of ARM > embedded system. > * defs.h (enum gdb_osabi): Add GDB_OSABI_PIKEOS. > * osabi.c (gdb_osabi_names): Add name for GDB_OSABI_PIKEOS. > > Tested on arm-pikeos and arm-elf using AdaCore's testsuite. > We also evaluated it on armhf-linux as a cross platform. > > OK to apply? > > Thanks! >