From patchwork Fri Mar 18 14:36:16 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yao Qi X-Patchwork-Id: 11378 Received: (qmail 23783 invoked by alias); 18 Mar 2016 14:36:36 -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 23759 invoked by uid 89); 18 Mar 2016 14:36:34 -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.192.193, Hx-spam-relays-external:209.85.192.193 X-HELO: mail-pf0-f193.google.com Received: from mail-pf0-f193.google.com (HELO mail-pf0-f193.google.com) (209.85.192.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 18 Mar 2016 14:36:24 +0000 Received: by mail-pf0-f193.google.com with SMTP id q129so17540325pfb.3 for ; Fri, 18 Mar 2016 07:36:24 -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=jKMQQCyTfGIyAiYqq+o7s+d5/+0n58LAsuHTJpOaCTA=; b=h9jbct6oneYDG2PlMdC+OZxnY/n3zCPSCF3qhlVE2LE4Vk9TrK2yhFT3UmUwR71D9E qCeA+qED8/DGW5pLZTYRdT+SJ5PUvvx72Kt80Xbyd+rpeisMFk1tV3CmBPq0jZtZ2mgY 30stHIydF2SKtKh4Prhi4l3eCrjSE3+DaMvYZVKFLxj9LWoWDwTpotS/Zrwc2CwoNyZy WSxyphm17moXm28tXaTDjWJr/j1vT6ZqgWkGc4ZM3CrN4teE5nL+9E2GRHBnj0FbEaYL 3/nZMMT/851TEYUqK3T43cJE/XjG0/y++miQHjxILFe8E8B+8jsRw1wqpQ89AMX4t7ZU keNQ== X-Gm-Message-State: AD7BkJL8fb+d8UUj806OKmEEJ9c810Nu3QQ6ySh6oFn1rbqjcpc3GJXGgfIYgQIHDfdP7A== X-Received: by 10.98.42.211 with SMTP id q202mr23984334pfq.13.1458311783151; Fri, 18 Mar 2016 07:36:23 -0700 (PDT) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id ud8sm21592502pac.11.2016.03.18.07.36.20 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 18 Mar 2016 07:36:22 -0700 (PDT) From: Yao Qi To: Pedro Alves Cc: Yao Qi , gdb-patches@sourceware.org Subject: Re: [PATCH 2/8] Check LWP_SIGNAL_CAN_BE_DELIVERED for enqueue/dequeue pending signals References: <1457088276-1170-1-git-send-email-yao.qi@linaro.org> <1457088276-1170-3-git-send-email-yao.qi@linaro.org> <56E2A42E.4080308@redhat.com> <86a8lxxzsu.fsf@gmail.com> <56EA8FFD.1040708@redhat.com> Date: Fri, 18 Mar 2016 14:36:16 +0000 In-Reply-To: <56EA8FFD.1040708@redhat.com> (Pedro Alves's message of "Thu, 17 Mar 2016 11:07:41 +0000") Message-ID: <86oaabx38f.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 X-IsSubscribed: yes Pedro Alves writes: > The comment is written in terms of "and", but the implementation is in > terms of "or", negated. > > If you write it like: > > return (lwp->bp_reinsert == 0 && !lwp->collecting_fast_tracepoint); > > then it matches exactly what the comment says, making it easier to > reason about. > > Otherwise LGTM. OK, patch below is what I pushed in, diff --git a/gdb/gdbserver/ChangeLog b/gdb/gdbserver/ChangeLog index b210971..a63d7fb 100644 --- a/gdb/gdbserver/ChangeLog +++ b/gdb/gdbserver/ChangeLog @@ -1,5 +1,10 @@ 2016-03-18 Yao Qi + * linux-low.c (lwp_signal_can_be_delivered): New function. + (linux_resume_one_lwp_throw): Use lwp_signal_can_be_delivered. + +2016-03-18 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. diff --git a/gdb/gdbserver/linux-low.c b/gdb/gdbserver/linux-low.c index f267a96..7630f9f 100644 --- a/gdb/gdbserver/linux-low.c +++ b/gdb/gdbserver/linux-low.c @@ -4118,6 +4118,16 @@ single_step (struct lwp_info* lwp) return step; } +/* 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. */ + +static int +lwp_signal_can_be_delivered (struct lwp_info *lwp) +{ + return (lwp->bp_reinsert == 0 && !lwp->collecting_fast_tracepoint); +} + /* Resume execution of LWP. If STEP is nonzero, single-step it. If SIGNAL is nonzero, give it that signal. */ @@ -4157,13 +4167,12 @@ linux_resume_one_lwp_throw (struct lwp_info *lwp, } /* If we have pending signals or status, and a new signal, enqueue the - signal. Also enqueue the signal if we are waiting to reinsert a - breakpoint; it will be picked up again below. */ + signal. Also enqueue the signal if it can't be delivered to the + inferior right now. */ if (signal != 0 && (lwp->status_pending_p || lwp->pending_signals != NULL - || lwp->bp_reinsert != 0 - || fast_tp_collecting)) + || !lwp_signal_can_be_delivered (lwp))) { enqueue_pending_signal (lwp, signal, info); @@ -4269,12 +4278,9 @@ linux_resume_one_lwp_throw (struct lwp_info *lwp, } } - /* If we have pending signals, consume one unless we are trying to - reinsert a breakpoint or we're trying to finish a fast tracepoint - collect. */ - if (lwp->pending_signals != NULL - && lwp->bp_reinsert == 0 - && fast_tp_collecting == 0) + /* If we have pending signals, consume one if it can be delivered to + the inferior. */ + if (lwp->pending_signals != NULL && lwp_signal_can_be_delivered (lwp)) { struct pending_signals **p_sig;