From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58281 invoked by alias); 16 Mar 2016 17:02:29 -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 58264 invoked by uid 89); 16 Mar 2016 17:02:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=describing, Hx-languages-length:1609, LWP X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 16 Mar 2016 17:02:18 +0000 Received: from svr-orw-fem-06.mgc.mentorg.com ([147.34.97.120]) by relay1.mentorg.com with esmtp id 1agEps-0004gV-Ig from Luis_Gustavo@mentor.com ; Wed, 16 Mar 2016 10:02:16 -0700 Received: from [172.30.3.160] (147.34.91.1) by SVR-ORW-FEM-06.mgc.mentorg.com (147.34.97.120) with Microsoft SMTP Server id 14.3.224.2; Wed, 16 Mar 2016 10:02:16 -0700 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> To: Yao Qi , From: Luis Machado Reply-To: Luis Machado Message-ID: <56E99194.3020102@codesourcery.com> Date: Wed, 16 Mar 2016 17:02: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: <1457088276-1170-3-git-send-email-yao.qi@linaro.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00258.txt.bz2 On 03/04/2016 07:44 AM, Yao Qi wrote: > The enqueue and dequeue signals in linux_resume_one_lwp_throw use one > condition and its inverted one. This patch is to move the condition > into a macro LWP_SIGNAL_CAN_BE_DELIVERED, so that the next patch can > change the condition in one place. > > gdb/gdbserver: > > 2016-03-04 Yao Qi > > * linux-low.c (LWP_SIGNAL_CAN_BE_DELIVERED): New macro. > (linux_resume_one_lwp_throw): Use LWP_SIGNAL_CAN_BE_DELIVERED. > --- > gdb/gdbserver/linux-low.c | 23 +++++++++++++---------- > 1 file changed, 13 insertions(+), 10 deletions(-) > > diff --git a/gdb/gdbserver/linux-low.c b/gdb/gdbserver/linux-low.c > index 4520a4a..dcf58db 100644 > --- a/gdb/gdbserver/linux-low.c > +++ b/gdb/gdbserver/linux-low.c > @@ -4118,6 +4118,13 @@ single_step (struct lwp_info* lwp) > return step; > } > > +/* 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. */ > + > +#define LWP_SIGNAL_CAN_BE_DELIVERED(LWP) \ > + !((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. */ > Should we state when a signal can be delivered as opposed to describing when it cannot be delivered? Or keep the description and change the macro/function to LWP_SIGNAL_CANNOT_BE_DELIVERED(LWP)? Otherwise the description won't match the macro/function. Otherwise looks fine to me.