From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5419 invoked by alias); 15 Nov 2018 18:01:34 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 4833 invoked by uid 89); 15 Nov 2018 18:01:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: gproxy1-pub.mail.unifiedlayer.com Received: from gproxy1-pub.mail.unifiedlayer.com (HELO gproxy1-pub.mail.unifiedlayer.com) (69.89.25.95) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 15 Nov 2018 18:01:32 +0000 Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id F30F744D3AE9A for ; Thu, 15 Nov 2018 10:50:42 -0700 (MST) Received: from box5008.bluehost.com ([50.116.64.19]) by cmsmtp with ESMTP id NLmsgoxOEVl4fNLmsg001g; Thu, 15 Nov 2018 10:50:42 -0700 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mad-scientist.us; s=default; h=Content-Transfer-Encoding:Mime-Version: Content-Type:References:In-Reply-To:Date:Cc:To:Reply-To:From:Subject: Message-ID:Sender:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XuLwg5Yi0lP22wSceNAWYn51PcNCWV87KmMtxVA+0dQ=; b=OK0YLe/v/AdTRqVbr/zqX5YEQJ /kUud8cxXbzw/19fJXMBjlRZq7vx5EU1dFkCM2TYk1aYyxFRUcZoC3RH8yDA2DNKkQl2P0wTOVK1d zn5enEYdPrX1HGFMU6hW+2pJV; Received: from pool-98-118-0-140.bstnma.fios.verizon.net ([98.118.0.140]:45862 helo=homebase) by box5008.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gNLCJ-001ePU-AZ; Thu, 15 Nov 2018 10:12:55 -0700 Message-ID: <6b62b6016ee54a525a4a78618be56b21f1e462df.camel@mad-scientist.net> Subject: Re: GDB (not) handling SIGINT...? From: Paul Smith Reply-To: paul@mad-scientist.net To: Pedro Alves , Simon Marchi Cc: gdb@sourceware.org Date: Thu, 15 Nov 2018 18:01:00 -0000 In-Reply-To: <276f4526-1873-0072-206c-c45bb47be3f6@redhat.com> References: <8003dfcd98e9a4d1e43f53220e0d446669944ead.camel@mad-scientist.net> <17a7ce8aa190956bd7a8ba9bd7cdea16@polymtl.ca> <8b205cb2ff59c49ab9f4ad98564dfea3f5d1586d.camel@mad-scientist.net> <276f4526-1873-0072-206c-c45bb47be3f6@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-11/txt/msg00008.txt.bz2 On Thu, 2018-11-15 at 16:24 +0000, Pedro Alves wrote: > With current GDB, you can work around this by attaching in non-stop > mode ("set non-stop on"), and then using "continue&" to continue in > the background, and the "interrupt" command to interrupt. Tricksy! > If you're OK with hacking GDB, s/SIGINT/SIGSTOP/g in child_pass_ctrlc > should work reasonably OK, even though not perfect. Oh, I understand now. The SIGINT is passed to the child to get it to stop. Somehow I assumed that there was a magical ptrace way to do this, rather than having to send normal signals. I guess there is now: using PTRACE_SEIZE instead of PTRACE_ATTACH, which will allow you to later send PTRACE_INTERRUPT: presumably if this were used would solve the problem for attached processes anyway...?