From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52012 invoked by alias); 9 Apr 2015 15:22:19 -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 51991 invoked by uid 89); 9 Apr 2015 15:22:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no 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:22:17 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t39FMFut009098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 9 Apr 2015 11:22:15 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t39FMDq4010441; Thu, 9 Apr 2015 11:22:14 -0400 Message-ID: <55269925.8090704@redhat.com> Date: Thu, 09 Apr 2015 15:22: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> In-Reply-To: <86y4m1uysh.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-04/txt/msg00337.txt.bz2 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: 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