From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34432 invoked by alias); 3 Feb 2017 16:13:44 -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 34359 invoked by uid 89); 3 Feb 2017 16:13:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= 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; Fri, 03 Feb 2017 16:13:42 +0000 Received: from smtp.corp.redhat.com (int-mx16.intmail.prod.int.phx2.redhat.com [10.5.11.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2559B83F3E; Fri, 3 Feb 2017 16:13:42 +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 A2E8E6F038; Fri, 3 Feb 2017 16:13:40 +0000 (UTC) Subject: Re: [PATCH 1/2] This patch fixes GDBServer's run control for single stepping To: Antoine Tremblay , Yao Qi References: <20161129120702.9490-1-antoine.tremblay@ericsson.com> <20170127150139.GB24676@E107787-LIN> Cc: "gdb-patches@sourceware.org" From: Pedro Alves Message-ID: <2255ed6f-a146-026c-f871-00e9a33dfcf0@redhat.com> Date: Fri, 03 Feb 2017 16:13:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-02/txt/msg00097.txt.bz2 On 01/30/2017 01:28 PM, Antoine Tremblay wrote: >> We don't change anything when setting breakpoint inside IT block. > > Well that's a problem if we write a 32 bit thumb2 breakpoint aligned on > 2 bytes like discussed before. Can we restrict the stopping-all-threads to the case that needs it, only? An optimization that would avoid this would be to use a hardware watchpoint/breakpoint (if available) for single-stepping. IIRC, you can ARM a breakpoint (or was it a watchpoint) on ARM for triggering when the PC is different from the current PC (or really, some specified address). In IT blocks, this would probably make the thread stop on instructions that aren't really executed (e.g., the then/else branches when the condition is correspondingly false/true), unlike the current solution where breakpoint instructions are not executed by the CPU when it falls on an instruction that isn't executed (because the breakpoint opcode we use it just some magic invalid instruction, node the BKPT instruction), but I think that when the thread stops, and we're stepping an IT block, we could look at the status registers and decide whether to single-step again. TBC, I'm not suggesting that we need to do that right now. The emulation solution discussed on the lkml thread made me thing of displaced stepping -- the ARM implementation emulates some instructions. I wonder whether displaced stepping over IT blocks is already handled correctly. Thanks, Pedro Alves