From patchwork Fri Mar 4 10:44:29 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yao Qi X-Patchwork-Id: 11185 Received: (qmail 109443 invoked by alias); 4 Mar 2016 10:44:47 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 109088 invoked by uid 89); 4 Mar 2016 10:44:46 -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=Hx-languages-length:4057, 42216, resuming X-HELO: mail-pf0-f195.google.com Received: from mail-pf0-f195.google.com (HELO mail-pf0-f195.google.com) (209.85.192.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 04 Mar 2016 10:44:45 +0000 Received: by mail-pf0-f195.google.com with SMTP id 63so2984578pfe.0 for ; Fri, 04 Mar 2016 02:44:45 -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=voj+CQDUoPmSosCsgilQFELP5InEXe0n3nkUYXOx1Ns=; b=cYziFvsIsexgF8iMwIHaFAxu8OeLUddMWNcUrAAEKt7CMF4b3hGKEW/RZxjq0ZlwKJ CD6KNiXaiYoQ8vooPXI5ZtbqbIiqeXxD5h0dgnnChoqlfunqnnjpeVcOYrHWOKx+MKgT wKc8YvJCZWUfZVhYTt2ECbZE9/76dd9E9ynreg8zaC6QKs8lpnh6RpT9ZKSttbzRgEkn dssvoX28qSgY5/X+KnaX9ACx0hMNsmjtLZK4yI5K4ExLYxq4PIdw+C7NipBdo1zubG/4 M1q1/njs3gEQgTrRVO3jhFOG3o3Xu1b8KBwBkyiNZ2om6Q4NPzfgsi9uWB2xCHO0SJ+g Hrlw== X-Gm-Message-State: AD7BkJI32YiiWGgSWQ3v/DVfQPRn/Y+ZK9hBc/v9tP3yurRIZgzjdA19+xpHorIslz4NHQ== X-Received: by 10.98.70.67 with SMTP id t64mr10918389pfa.110.1457088283518; Fri, 04 Mar 2016 02:44:43 -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.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 04 Mar 2016 02:44:42 -0800 (PST) From: Yao Qi X-Google-Original-From: Yao Qi To: gdb-patches@sourceware.org Subject: [PATCH 1/8] Set signal to 0 after enqueue_pending_signal Date: Fri, 4 Mar 2016 10:44:29 +0000 Message-Id: <1457088276-1170-2-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 Today, we enqueue signal in linux_resume_one_lwp_throw, but set variable 'signal' many lines below with the comment /* Postpone any pending signal. It was enqueued above. */ signal = 0; I feel difficult to associate code across many lines, and we should move the code close to enqueue_pending_signal call. This is what this patch does in general. After this change, variable 'signal' is set to zero very early, so the 'signal' value in the following debugging message makes no sense, so I remove it from the debugging message. The function returns early if lwp->status_pending_p is true, so 'signal' value in the debugging message doesn't matter, AFAICS. Also, I move one debugging message several lines below to make it close the real ptrace call, if (debug_threads) debug_printf ("Resuming lwp %ld (%s, signal %d, stop %s)\n", lwpid_of (thread), step ? "step" : "continue", signal, lwp->stop_expected ? "expected" : "not expected"); so that the debugging message can reflect what GDBserver does. This is a code refactor and only debugging messages are affected. gdb/gdbserver: 2016-03-04 Yao Qi * linux-low.c (linux_resume_one_lwp_throw): Set 'signal' to 0 if signal is enqueued. Remove 'signal' from one debugging message. Move one debugging message to some lines below. Remove code setting 'signal' to 0. --- gdb/gdbserver/linux-low.c | 30 +++++++++++++----------------- 1 file changed, 13 insertions(+), 17 deletions(-) diff --git a/gdb/gdbserver/linux-low.c b/gdb/gdbserver/linux-low.c index b96248c..4520a4a 100644 --- a/gdb/gdbserver/linux-low.c +++ b/gdb/gdbserver/linux-low.c @@ -4164,14 +4164,19 @@ linux_resume_one_lwp_throw (struct lwp_info *lwp, || lwp->pending_signals != NULL || lwp->bp_reinsert != 0 || fast_tp_collecting)) - enqueue_pending_signal (lwp, signal, info); + { + enqueue_pending_signal (lwp, signal, info); + + /* Postpone any pending signal. It was enqueued above. */ + signal = 0; + } if (lwp->status_pending_p) { if (debug_threads) - debug_printf ("Not resuming lwp %ld (%s, signal %d, stop %s);" + debug_printf ("Not resuming lwp %ld (%s, stop %s);" " has pending status\n", - lwpid_of (thread), step ? "step" : "continue", signal, + lwpid_of (thread), step ? "step" : "continue", lwp->stop_expected ? "expected" : "not expected"); return; } @@ -4179,11 +4184,6 @@ linux_resume_one_lwp_throw (struct lwp_info *lwp, saved_thread = current_thread; current_thread = thread; - if (debug_threads) - debug_printf ("Resuming lwp %ld (%s, signal %d, stop %s)\n", - lwpid_of (thread), step ? "step" : "continue", signal, - lwp->stop_expected ? "expected" : "not expected"); - /* This bit needs some thinking about. If we get a signal that we must report while a single-step reinsert is still pending, we often end up resuming the thread. It might be better to @@ -4213,9 +4213,6 @@ linux_resume_one_lwp_throw (struct lwp_info *lwp, step = 1; } - - /* Postpone any pending signal. It was enqueued above. */ - signal = 0; } if (fast_tp_collecting == 1) @@ -4224,9 +4221,6 @@ linux_resume_one_lwp_throw (struct lwp_info *lwp, debug_printf ("lwp %ld wants to get out of fast tracepoint jump pad" " (exit-jump-pad-bkpt)\n", lwpid_of (thread)); - - /* Postpone any pending signal. It was enqueued above. */ - signal = 0; } else if (fast_tp_collecting == 2) { @@ -4243,9 +4237,6 @@ linux_resume_one_lwp_throw (struct lwp_info *lwp, "moving out of jump pad single-stepping" " not implemented on this target"); } - - /* Postpone any pending signal. It was enqueued above. */ - signal = 0; } /* If we have while-stepping actions in this thread set it stepping. @@ -4300,6 +4291,11 @@ linux_resume_one_lwp_throw (struct lwp_info *lwp, *p_sig = NULL; } + if (debug_threads) + debug_printf ("Resuming lwp %ld (%s, signal %d, stop %s)\n", + lwpid_of (thread), step ? "step" : "continue", signal, + lwp->stop_expected ? "expected" : "not expected"); + if (the_low_target.prepare_to_resume != NULL) the_low_target.prepare_to_resume (lwp);