From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89614 invoked by alias); 17 Mar 2016 12:40:16 -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 88911 invoked by uid 89); 17 Mar 2016 12:40:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=Hx-languages-length:1895 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 17 Mar 2016 12:40:06 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 5AE08627C0; Thu, 17 Mar 2016 12:40:05 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2HCe4MB015939; Thu, 17 Mar 2016 08:40:04 -0400 Subject: Re: [PATCH 4/8] Force to insert software single step breakpoint To: Yao Qi References: <1457088276-1170-1-git-send-email-yao.qi@linaro.org> <1457088276-1170-5-git-send-email-yao.qi@linaro.org> <56E2B0C2.705@redhat.com> <86egbay78l.fsf@gmail.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <56EAA5A4.5040601@redhat.com> Date: Thu, 17 Mar 2016 12:40:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <86egbay78l.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-03/txt/msg00309.txt.bz2 On 03/16/2016 11:47 AM, Yao Qi wrote: > Pedro Alves writes: > >> Hmm, I think we might need to do something else. >> >> If you put a breakpoint there, then the instruction under >> the breakpoint won't execute at all. > > That is intended, because if the instruction is executed, it can't be > stopped. > >> >> If it's a conditional branch, and the condition is false, >> we will fail to ever advance past the instruction. >> >> Similarly if the branch instruction happens to have important >> side effects (flags? counters?). > > We can switch to displaced stepping if we find the instruction may > branch to itself. Say, we can change gdbarch software_single_step to > return a vector of dest addresses of current pc and caller inserts > software single step breakpoints to these dest addresses. If any > element of vector equals to the current pc, switch to displaced > stepping if supported. What do you think? That's not possible on the gdbserver side, however. Maybe what we need to do is firmly declare (and add comments in that direction) that the arch's get_next_pcs implementation must always evaluate the condition of conditional branches, and not put a breakpoint at the branch destination if the condition is false, thus ensuring forward progress. The ARM implementation does this, though I haven't checked whether all the branch instructions are covered. Some other archs don't, and always put a break at the branch destination, like e.g., moxie_software_single_step. If we find some instruction where that is still not be sufficient, due to side effects, then maybe gdb and gdbserver could first try emulating the instruction's side effects manually. And only if that doesn't work, then try displaced stepping. We could leave that for later, until we find a need. WDYT? Thanks, Pedro Alves