From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47329 invoked by alias); 11 Mar 2016 11:37:53 -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 47318 invoked by uid 89); 11 Mar 2016 11:37:53 -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=$pc, stepped, nest 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; Fri, 11 Mar 2016 11:37:43 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 0D2FD8E70E; Fri, 11 Mar 2016 11:37:42 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2BBbeud012582; Fri, 11 Mar 2016 06:37:41 -0500 Subject: Re: [PATCH 3/8] Deliver signal in hardware single step To: Yao Qi , gdb-patches@sourceware.org References: <1457088276-1170-1-git-send-email-yao.qi@linaro.org> <1457088276-1170-4-git-send-email-yao.qi@linaro.org> <56E2A685.2080602@redhat.com> <56E2A753.9060805@redhat.com> From: Pedro Alves Message-ID: <56E2AE04.7030306@redhat.com> Date: Fri, 11 Mar 2016 11:37: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: <56E2A753.9060805@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-03/txt/msg00182.txt.bz2 On 03/11/2016 11:09 AM, Pedro Alves wrote: > On 03/11/2016 11:05 AM, Pedro Alves wrote: >> On 03/04/2016 10:44 AM, Yao Qi wrote: >>> GDBserver doesn't deliver signal when stepping over a breakpoint even >>> hardware single step is used. When GDBserver started to step over >>> (thread creation) breakpoint for mutlit-threaded debugging in 2002 [1], >>> GDBserver behaves this way. >>> >>> This behaviour gets trouble on conditional breakpoints on branch to >>> self instruction like this, >>> >>> 0x00000000004005b6 <+29>: jmp 0x4005b6 >>> >>> and I set breakpoint >>> >>> $(gdb) break branch-to-self.c:43 if counter > 3 >>> >>> and the variable counter will be set to 5 in SIGALRM signal handler. >>> Since GDBserver keeps stepping over breakpoint, the SIGALRM can never >>> be dequeued and delivered to the inferior, so the program can't stop. >>> The test can be found in gdb.base/branch-to-self.exp. >>> >>> I can understand why does GDBserver queue signal for software single >>> step, but I can't figure out a reason we should queue signal for >>> hardware single step. With this patch applied, GDBserver forward the >>> signal to inferior and the program can stop correctly. >>> >>> [1] PATCH: Multithreaded debugging for gdbserver >>> https://sourceware.org/ml/gdb-patches/2002-06/msg00157.html >>> >> >> Because the signal handler might recurse and call the same code >> that had the breakpoint (or some other removed breakpoint), and thus >> we'd miss a breakpoint hit in the signal handler. > > Hmm, no, I got confused. We'll stop in first instruction in the signal > handler. Let me go back and take a fresh look. OK, trying to think of scenarios that might break. Haven't actually tried them, I may have missed something. - If there's no handler installed at all (SIG_IGN), then we'll manage to step over the breakpoint successfully and stop at the next instruction. So this case is not an issue. - If there's a signal handler installed, we'll stop at its entry, but we haven't stepped over the original breakpoint yet. If we were already stopped at the entry of the signal handler, and it nested, we'll find the program stopped at the same PC it had started at. But we won't know whether the step-over finished successfully (could be a "jmp $pc" instruction), or if instead we're in a new handler invocation, and thus this is a new, separate breakpoint hit. A signal handler that segfaults in the first instruction would be the easiest way to reproduce this that I can think of. (If it's crashing, you'd expect the user might try putting a breakpoint there.) Now, if after stepping into the handler, we immediately reinsert the breakpoint and continue, we'll retrap it, it ends up OK. But if we immediately instead start a new step-over for the same breakpoint address, we will miss the new hit, and nest a new handler, on and on. Not sure which happens, but I suspect the latter. Maybe we could detect this by comparing before / after stack pointer. Thanks, Pedro Alves