From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65748 invoked by alias); 9 Apr 2015 15:25:01 -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 65367 invoked by uid 89); 9 Apr 2015 15:25:01 -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:25:00 +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 t39FOw8d019132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 9 Apr 2015 11:24:58 -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 t39FOuH0003062; Thu, 9 Apr 2015 11:24:57 -0400 Message-ID: <552699C8.9070001@redhat.com> Date: Thu, 09 Apr 2015 15:25: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> In-Reply-To: <55269925.8090704@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-04/txt/msg00338.txt.bz2 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. > > void > function () > { > i = 0; > i = 0; // set cond breakpoint that evals false here > i = 0; > } > > I'd guess the "si" over the breakpoint ends in the caller > of "function"... Thanks, Pedro Alves