From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 8WSQO2p02mCSHgAAWB0awg (envelope-from ) for ; Mon, 28 Jun 2021 21:16:26 -0400 Received: by simark.ca (Postfix, from userid 112) id E55F41F1F2; Mon, 28 Jun 2021 21:16:26 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id F27CE1E01F for ; Mon, 28 Jun 2021 21:16:25 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3AE0E383D02D for ; Tue, 29 Jun 2021 01:16:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3AE0E383D02D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1624929385; bh=XcyLBgC/FGnUZiUoGhX85b3HjlpOkR6BS6srU7cYCbY=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=fAKBSkwH5Q88bSzf0u7kNtuC50T2I0XpSAalAD3O2OBGgD2T2flAm5o4aqCa1vSBA OX439BlDmsk7MJj3vxs7z/GmkBXc9Ah5vWgIwZWQY2pAdCZU626zHQYGutejdN2OdS zT9W4+efj2UDcjG6lPz39gghycy9qEdDD2DLJA2U= Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) by sourceware.org (Postfix) with ESMTPS id 1E16B3847825 for ; Tue, 29 Jun 2021 01:16:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1E16B3847825 Received: by mail-ej1-x62e.google.com with SMTP id o11so20064721ejd.4 for ; Mon, 28 Jun 2021 18:16:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XcyLBgC/FGnUZiUoGhX85b3HjlpOkR6BS6srU7cYCbY=; b=V14UFxM9IqjbN56l3+0T0pQzLxdAYOUDyZb2CZbT4hqAtCoJ6rpprVbiCZ3ADy9Vev oBPKZfpcJA0gURRKHyS6r6SpK0hMMcCPqW1dedIxlGKff73AO3q3zVX1tqf37Fgxppx3 yleTaS0aHPq5cimIXWOOWGhtdHxvNiMwlfMjUCcdJaz9OS7RNKlb8OzHL44WFp7OWs3Q mC+oKC5ihxb36uI3QafcVattMUg+89WQw4WBX0KMyuEVbmtCzTZ5aHX5PyhtSny/dqPv QwQYjJzRArS3EXMbEKxRwW/F3A8UzKkdfVtFATrcRW0NXqJkn+onew9i+AWT9gzsisIQ 0ROQ== X-Gm-Message-State: AOAM530yXuDCrT+p/NWc5SBmIG2Uj79ToKPS3SdVcMkBWo93HK/vUzZV DXtQVQrVXDziK+I/AWqAeGLWpBcLH4yAk7dTG1NqQOIuAphj/Nn/ X-Google-Smtp-Source: ABdhPJyIxRx3q8pe9ssxCsM3rO+fM1dDlu33bNMBTEJk8sHZmRWJmwtRdBzrKWIqxnK68K2M2FxDkgZ9hZWrF83WpOU= X-Received: by 2002:a17:907:264b:: with SMTP id ar11mr26242987ejc.525.1624929361232; Mon, 28 Jun 2021 18:16:01 -0700 (PDT) MIME-Version: 1.0 References: <20210614212410.1612666-1-pedro@palves.net> <1c54ccee2e4a2980b0a0e5b7e50818970662afc2.camel@yandex.ru> In-Reply-To: Date: Tue, 29 Jun 2021 04:15:50 +0300 Message-ID: Subject: Re: [PATCH v2 00/16] Interrupting programs that block/ignore SIGINT To: Pedro Alves Content-Type: text/plain; charset="UTF-8" X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Eldar Abusalimov via Gdb-patches Reply-To: Eldar Abusalimov Cc: gdb-patches@sourceware.org, Konstantin Kharlamov Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Hi Pedro, Let me chime in to say that the issue addressed is indeed relevant, in case you need any reassurance. :-) This being addressed is great news! A related problem[1] was reported in the CLion IDE issue tracker, and the discussion also mentions the Kernel PR linked by Konstantin. Since CLion signals the inferior process directly, we ended up changing the signal sent by the IDE from SIGINT to SIGSTOP so that there's no way the inferior program can intercept the signal. Apparently, this is also how LLDB handles that as well. However, that didn't cover[2] the target-async case, that is, when the signal is still being sent by GDB (using the "interrupt" command), and remote targets, where it's the gdbserver who ultimately supervises the inferior process, not GDB. >From the patchset, I gather that the target-async case has now been fixed as well, but what about remote targets? Do you think it makes sense to also change gdbserver to use SIGSTOP instead of SIGINT? As far as I understand, unlike for a locally spawned process, this shouldn't require waltzing with pseudo-terminals for the inferior on the remote gdbserver side. At the same time consistency w.r.t. signal handling on suspending the target would definitely be a nice thing to have eventually. [1]: https://youtrack.jetbrains.com/issue/CPP-14435#focus=Comments-27-3105589.0-0 [2]: https://youtrack.jetbrains.com/issue/CPP-21975#focus=Comments-27-4635249.0-0 -- Regards, Eldar