From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3114 invoked by alias); 15 Nov 2018 18:27:07 -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 3096 invoked by uid 89); 15 Nov 2018 18:27:06 -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=ere X-HELO: outbound-ss-579.bluehost.com Received: from outbound-ss-579.bluehost.com (HELO outbound-ss-579.bluehost.com) (74.220.218.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 15 Nov 2018 18:27:05 +0000 Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 617B51E1174 for ; Thu, 15 Nov 2018 11:27:02 -0700 (MST) Received: from box5008.bluehost.com ([50.116.64.19]) by cmsmtp with ESMTP id NMKpgqp9oVl4fNMKpg1rcR; Thu, 15 Nov 2018 11:25:48 -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=ru5wOedtfM99fEKoCzY3sRjycW1gs6/0tSykMTrajQ4=; b=T5HRmecWx2+dmzEDPOTkguzIzY nb2lYCcwWiViubBU6BgfRaozAcfHFKGZFlc0Eu+3WW90TIE7jPO/U1+P2tvDU37gHF/GDxOqm1j7m lSCINN8nrecO4mXUm0hX8qC+Y; Received: from pool-98-118-0-140.bstnma.fios.verizon.net ([98.118.0.140]:47918 helo=homebase) by box5008.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gNMKo-0029yE-KO; Thu, 15 Nov 2018 11:25:46 -0700 Message-ID: <950f7a3f3c841a691fbcbf6a9cceb37964b61ad2.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:27:00 -0000 In-Reply-To: <735333d4-aeef-f10f-9623-cf3f67da3145@redhat.com> References: <8003dfcd98e9a4d1e43f53220e0d446669944ead.camel@mad-scientist.net> <17a7ce8aa190956bd7a8ba9bd7cdea16@polymtl.ca> <8b205cb2ff59c49ab9f4ad98564dfea3f5d1586d.camel@mad-scientist.net> <276f4526-1873-0072-206c-c45bb47be3f6@redhat.com> <6b62b6016ee54a525a4a78618be56b21f1e462df.camel@mad-scientist.net> <735333d4-aeef-f10f-9623-cf3f67da3145@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-11/txt/msg00010.txt.bz2 On Thu, 2018-11-15 at 18:04 +0000, Pedro Alves wrote:> > > I guess there is now: using PTRACE_SEIZE instead of PTRACE_ATTACH, > > which will allow you to later send PTRACE_INTERRUPT: presumably if this > > ere used would solve the problem for attached processes anyway...? > Yup, assuming we're OK with "ctrl-c" in the GDB console not > resulting in SIGINT. It seems to me that, as long as nopass is set on SIGINT, that would be the expected/correct behavior... is there something unexpected about the way it would work? I'll look at using SIGSTOP instead of SIGINT, for my situation.