From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113380 invoked by alias); 4 Mar 2016 10:44: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 112904 invoked by uid 89); 4 Mar 2016 10:44:52 -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=H*RU:209.85.220.68, Hx-spam-relays-external:209.85.220.68, STEP, SIGALRM X-HELO: mail-pa0-f68.google.com Received: from mail-pa0-f68.google.com (HELO mail-pa0-f68.google.com) (209.85.220.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 04 Mar 2016 10:44:48 +0000 Received: by mail-pa0-f68.google.com with SMTP id gc2so2225398pab.0 for ; Fri, 04 Mar 2016 02:44:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references; bh=z0lgGI45SixilTjJJZOJSwa/dLvVNPB6iYUs3ywk0OU=; b=Kv3r3mCBTnP+r2gCPfINr9+6N8p5v7rpZlIW+gwdJvUBuRJBsKqucdA4bJowd5sSol XvlxFYjw+6guBJdARAv4FeBFILa2daKq1kER2k1kXwbASr6A/rQg2R+ktwrVbuyjBdE2 C8au5MWZL4YeyV65ChfEBKDy83BA23w4E3o6oVeGf4mhg8smr/je/zwIlx/4/wDflaDv O6shg/hkLTcgaIQSF6fWPUD1YsVANcD5vsm739cW9rbEpkuQujXaKzVdRC+VYfBE0PRU TI0lIwGoJt1Mj0emjafoqdFsxsF46bulxXP/Qp6kCXuzZuGMNIBhFgSattHB6LK+95w1 RGPg== X-Gm-Message-State: AD7BkJKJ5p2PqQXA9gSXEfs97BoBlXny6Gwyn/mVIjZkRS5bhfZbsJvobf3HjGfGLaymaw== X-Received: by 10.66.255.39 with SMTP id an7mr10952369pad.2.1457088286085; Fri, 04 Mar 2016 02:44:46 -0800 (PST) Received: from E107787-LIN.cambridge.arm.com (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id e20sm4604321pfd.4.2016.03.04.02.44.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 04 Mar 2016 02:44:45 -0800 (PST) From: Yao Qi X-Google-Original-From: Yao Qi To: gdb-patches@sourceware.org Subject: [PATCH 3/8] Deliver signal in hardware single step Date: Fri, 04 Mar 2016 10:44:00 -0000 Message-Id: <1457088276-1170-4-git-send-email-yao.qi@linaro.org> In-Reply-To: <1457088276-1170-1-git-send-email-yao.qi@linaro.org> References: <1457088276-1170-1-git-send-email-yao.qi@linaro.org> X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00069.txt.bz2 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 gdb/gdbserver: 2016-03-04 Yao Qi * linux-low.c (LWP_SIGNAL_CAN_BE_DELIVERED): Don't deliver signal when stepping over breakpoint with software single step. --- gdb/gdbserver/linux-low.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/gdb/gdbserver/linux-low.c b/gdb/gdbserver/linux-low.c index dcf58db..2330e67 100644 --- a/gdb/gdbserver/linux-low.c +++ b/gdb/gdbserver/linux-low.c @@ -4119,11 +4119,12 @@ single_step (struct lwp_info* lwp) } /* The signal can not be delivered to the inferior if we are trying to - reinsert a breakpoint or we're trying to finish a fast tracepoint - collect. */ + reinsert a breakpoint for software single step or we're trying to + finish a fast tracepoint collect. */ -#define LWP_SIGNAL_CAN_BE_DELIVERED(LWP) \ - !((LWP)->bp_reinsert != 0 || (LWP)->collecting_fast_tracepoint) +#define LWP_SIGNAL_CAN_BE_DELIVERED(LWP) \ + !(((LWP)->bp_reinsert != 0 && can_software_single_step ()) \ + || (LWP)->collecting_fast_tracepoint) /* Resume execution of LWP. If STEP is nonzero, single-step it. If SIGNAL is nonzero, give it that signal. */ -- 1.9.1