From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72168 invoked by alias); 9 Apr 2015 15:29:52 -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 72155 invoked by uid 89); 9 Apr 2015 15:29:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 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, 09 Apr 2015 15:29:50 +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 (8.14.4/8.14.4) with ESMTP id t39FTmwE017810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 9 Apr 2015 11:29:48 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t39FTkem005818; Thu, 9 Apr 2015 11:29:47 -0400 Message-ID: <55269AEA.8080007@redhat.com> Date: Thu, 09 Apr 2015 15:29:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [PATCH] gdbserver gnu/linux: stepping over breakpoint References: <1428569112-18004-1-git-send-email-qiyaoltc@gmail.com> <552645C2.6080004@redhat.com> <86y4m1uysh.fsf@gmail.com> <55269925.8090704@redhat.com> <552699C8.9070001@redhat.com> In-Reply-To: <552699C8.9070001@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-04/txt/msg00339.txt.bz2 On 04/09/2015 04:24 PM, Pedro Alves wrote: > On 04/09/2015 04:22 PM, Pedro Alves wrote: >> On 04/09/2015 04:06 PM, Yao Qi wrote: >>> Pedro Alves writes: >>> >>>> even reached. The test isn't even threaded. It sounds like >>>> gdbserver is trying to step over the breakpoint at "foo"? Didn't >>>> gdb itself step over it? How come that was reached in gdbserver? >>>> Did we mishandle the breakpoint's reference count in gdbserver? >>> >>> Shouldn't GDBserver step over breakpoint when the target side condition >>> is false? >> >> Oh, this is stepping past an hardware breakpoint, not software >> breakpoint. Yes, GDBserver should be stepping past such >> breakpoints. But, given GDBserver's software single-step >> support is really really really really too simple: >> >> /* We only place breakpoints in empty marker functions, and thread locking >> is outside of the function. So rather than importing software single-step, >> we can just run until exit. */ >> static CORE_ADDR >> arm_reinsert_addr (void) >> { >> struct regcache *regcache = get_thread_regcache (current_thread, 1); >> unsigned long pc; >> collect_register_by_name (regcache, "lr", &pc); >> return pc; >> } >> >> ... we should probably disable target side conditions on software >> single-step gdbserver ports. E.g., try "si" through this function: > > Sorry, "si" probably works as gdb steps over the breakpoint > itself. Try "step" or "next" instead, which kick in the range > stepping support, which then causes gdbserver to handle the > step-over itself. Hmm^2, no, range stepping couldn't possibly work correctly with that limited software single-step support. Duh. We only enable range stepping on x86, even. So maybe that's "good enough" for stepping past conditional breakpoints in practice. Guess we should update the comments to mention this. Thanks, Pedro Alves