From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28982 invoked by alias); 1 Jul 2016 16:55:30 -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 28969 invoked by uid 89); 1 Jul 2016 16:55:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=queued X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 01 Jul 2016 16:55:21 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EEEFA7F6A8; Fri, 1 Jul 2016 16:55:19 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u61GtIsx015132; Fri, 1 Jul 2016 12:55:19 -0400 Subject: Re: [PATCH 7/9] Enqueue signal even when resuming threads To: Yao Qi References: <1467295765-3457-1-git-send-email-yao.qi@linaro.org> <1467295765-3457-8-git-send-email-yao.qi@linaro.org> <4a3c91d8-85bb-31f2-7f9e-bc0fe0de0ff6@redhat.com> Cc: "gdb-patches@sourceware.org" From: Pedro Alves Message-ID: <4b9dce0a-023f-964c-77e4-85154d7087f2@redhat.com> Date: Fri, 01 Jul 2016 16:55:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-07/txt/msg00016.txt.bz2 On 07/01/2016 05:45 PM, Yao Qi wrote: > You meant "after resuming it" rather than "before resuming it", right? We have > two pending signals, so we resume the lwp and deliver the first signal. After > resuming, we need to immediately deliver the second signal, so we call > send_sigstop. No, I really meant "before resuming it". We'd queue a SIGSTOP in the kernel, and then resume the thread with PTRACE_CONTINUE/STEP + signal. The idea being that the thread would continue out of the signal delivery path in the kernel side with the signal we resume it with, so if there's a signal handler, it's what the kernel makes the thread execute as soon as it reaches userspace. But given we had _also_ queued a SIGSTOP, the thread would immediately report the SIGSTOP before it had a chance of executing the first instruction of the handler. IOW, it'd report the SIGSTOP in the first instruction of the handler, or where it was already stopped before, if the signal signal passed to PTRACE_CONTINUE is SIG_IGN. Seeing the thread stop for a SIGSTOP that gdbserver had itself sent, gdbserver would immediately re-resume the thread, this time, with the other pending signal. This latter part probably already works without any change. See tail end of linux_low_filter_event, where we have: if (WIFSTOPPED (wstat) && WSTOPSIG (wstat) == SIGSTOP && child->stop_expected) { if (debug_threads) debug_printf ("Expected stop.\n"); child->stop_expected = 0; > IIUC, this patch is OK as-is, right? > Yes. Thanks, Pedro Alves