From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28894 invoked by alias); 22 Apr 2016 10:54:42 -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 28881 invoked by uid 89); 22 Apr 2016 10:54:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=canceled, Deliver, arrives, Hx-languages-length:4307 X-HELO: mail-pa0-f52.google.com Received: from mail-pa0-f52.google.com (HELO mail-pa0-f52.google.com) (209.85.220.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 22 Apr 2016 10:54:34 +0000 Received: by mail-pa0-f52.google.com with SMTP id er2so38842502pad.3 for ; Fri, 22 Apr 2016 03:54:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=8S3OjLkMIpqFEXCb4aFJDNsbPTaUPf/q4DQtJ+E5bCk=; b=J4K57O+UmwtOlltKkg+ktdWVRCqiai1UXwfFjORkFbFM/dVVaOwNj0Lp61IITo6X4B SSZdqks6kdOYZKaiYEatgY/92SxN18AobprSpKM1Ee/7Lv9T5fVkMD7LKxSQ+z9tredk c1oYJ/ibbAGMbuRDTGCeHsrZUXGU/J4JY0Y3dUK/HdHl9by+4153ae57dWBy3COSbXU7 S1fcgfqMu6zDlB/3cRfWXqt64GPpuNQ1jc8iHBDDZQZzAUibDtvd5KOoPShHQ+BiTkFO XFi7OxtlpA4Xpiyd29Zux9pI/pQ/kuRsvcdM9Dfie7UQuq5pKY9PAfHzo6ENTcxzL1BG GsRQ== X-Gm-Message-State: AOPr4FU5NTAU9JhhXlZpkhOooNHu7XW/dE+zM8oVLnaVmIPi/sMpv4dek7SSafl+szUtwQ== X-Received: by 10.67.6.10 with SMTP id cq10mr27405338pad.120.1461322472669; Fri, 22 Apr 2016 03:54:32 -0700 (PDT) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id xs10sm8796385pab.4.2016.04.22.03.54.30 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 22 Apr 2016 03:54:32 -0700 (PDT) From: Yao Qi To: Pedro Alves Cc: Yao Qi , gdb-patches@sourceware.org Subject: Re: [PATCH 2/7] Deliver signal in hardware single step References: <1458749384-19793-1-git-send-email-yao.qi@linaro.org> <1458749384-19793-3-git-send-email-yao.qi@linaro.org> <570BB039.1060806@redhat.com> Date: Fri, 22 Apr 2016 10:54:00 -0000 In-Reply-To: <570BB039.1060806@redhat.com> (Pedro Alves's message of "Mon, 11 Apr 2016 15:10:01 +0100") Message-ID: <86eg9xj4mk.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00514.txt.bz2 Pedro Alves writes: > making test result diffing unstable. If so, I think it should > either be written as: > > pass "tracepoint $i hit $iterations times (spurious collection)" > I prefer this. > making use of the rule that terminating " (...)" bits don't really > count as test message, or always: > > pass "tracepoint $i hit $iterations times" > > Otherwise LGTM. Patch below is pushed in. --=20 Yao (=E9=BD=90=E5=B0=A7) =46rom b3273b50e69dda8ac50278ab9cc57e67e4f45465 Mon Sep 17 00:00:00 2001 From: Yao Qi Date: Thu, 3 Mar 2016 08:58:52 +0000 Subject: [PATCH] Deliver signal in hardware single step 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 behavior 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. GDBserver didn't deliver signal when stepping over a breakpoint because a tracepoint is collected twice if GDBserver does so in the following scenario, which can be reproduced by gdb.trace/signal.exp. - program stops at tracepoint, and tracepoint is collected, - gdbserver starts a step-over, - a signal arrives, step-over is canceled, and signal should be passed, - gdbserver starts a new step-over again, pass the signal as well, - program stops at the entry of signal handler, step-over finished, - gdbserver proceeds, - program returns from the signal handler, again to the tracepoint, and thus is collected again. The spurious collection isn't that harmful, IMO, so it should be OK to let GDBserver deliver signal when stepping over a breakpoint. gdb/gdbserver: 2016-04-22 Yao Qi * linux-low.c (lwp_signal_can_be_delivered): Don't deliver signal when stepping over breakpoint with software single step. gdb/testsuite: 2016-04-22 Yao Qi * gdb.trace/signal.exp: Also pass if $tracepoint_hits($i) > $iterations. diff --git a/gdb/gdbserver/linux-low.c b/gdb/gdbserver/linux-low.c index 2cf192e..7e55349 100644 --- a/gdb/gdbserver/linux-low.c +++ b/gdb/gdbserver/linux-low.c @@ -4118,13 +4118,17 @@ single_step (struct lwp_info* lwp) } =20 /* The signal can be delivered to the inferior if we are not trying to - reinsert a breakpoint and not trying to finish a fast tracepoint - collect. */ + reinsert a breakpoint for software single step and not trying to + finish a fast tracepoint collect. Since signal can be delivered in + the step-over, the program may go to signal handler and trap again + after return from the signal handler. We can live with the spurious + double traps. */ =20 static int lwp_signal_can_be_delivered (struct lwp_info *lwp) { - return (lwp->bp_reinsert =3D=3D 0 && !lwp->collecting_fast_tracepoint); + return (!(lwp->bp_reinsert !=3D 0 && can_software_single_step ()) + && !lwp->collecting_fast_tracepoint); } =20 /* Resume execution of LWP. If STEP is nonzero, single-step it. If diff --git a/gdb/testsuite/gdb.trace/signal.exp b/gdb/testsuite/gdb.trace/s= ignal.exp index 7118a9f..48e495e 100644 --- a/gdb/testsuite/gdb.trace/signal.exp +++ b/gdb/testsuite/gdb.trace/signal.exp @@ -174,6 +174,14 @@ while { 1 } { # Step 3, check the number of collections on each tracepoint. =20 for { set i $tpnum } { $i < [expr $tpnum + 2] } { incr i } { - gdb_assert { $tracepoint_hits($i) =3D=3D $iterations } \ - "tracepoint $i hit $iterations times" + + if { $tracepoint_hits($i) =3D=3D $iterations } { + pass "tracepoint $i hit $iterations times" + } elseif { $tracepoint_hits($i) > $iterations } { + # GDBserver deliver the signal while stepping over tracepoint, + # so it is possible that a tracepoint is collected twice. + pass "tracepoint $i hit $iterations times (spurious collection)" + } else { + fail "tracepoint $i hit $iterations times" + } }