From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75749 invoked by alias); 15 Nov 2018 16:01:58 -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 75739 invoked by uid 89); 15 Nov 2018 16:01:57 -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=_always_, our X-HELO: gproxy3-pub.mail.unifiedlayer.com Received: from gproxy3-pub.mail.unifiedlayer.com (HELO gproxy3-pub.mail.unifiedlayer.com) (69.89.30.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 15 Nov 2018 16:01:56 +0000 Received: from cmgw14.unifiedlayer.com (unknown [10.9.0.14]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id A4E4D43157 for ; Thu, 15 Nov 2018 08:51:29 -0700 (MST) Received: from box5008.bluehost.com ([50.116.64.19]) by cmsmtp with ESMTP id NJvVg2c91vdTuNJvVgJgky; Thu, 15 Nov 2018 08:51:29 -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=r9h9Fbpz1HKUvb+pUK4pEbewVV3iZuVm33DN+s/dpKM=; b=ra5mFiAD7LMTawNSwDyeUY/VM/ pNT2z0zdVmofsXEGJ5zYxV9PQmpJ4cQym+ZULpHfLiVtbOn6O+qYFVV9/cbBeNDvRPuF7eT2Uye1K PslKAbne7ih/+T79B8Si6Zp1K; Received: from pool-98-118-0-140.bstnma.fios.verizon.net ([98.118.0.140]:43344 helo=homebase) by box5008.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gNJvV-0015lW-23; Thu, 15 Nov 2018 08:51:29 -0700 Message-ID: <8b205cb2ff59c49ab9f4ad98564dfea3f5d1586d.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 16:01:00 -0000 In-Reply-To: References: <8003dfcd98e9a4d1e43f53220e0d446669944ead.camel@mad-scientist.net> <17a7ce8aa190956bd7a8ba9bd7cdea16@polymtl.ca> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Org: HG=bhcustomer;ORG=bluehost; X-SW-Source: 2018-11/txt/msg00006.txt.bz2 On Thu, 2018-11-15 at 13:55 +0000, Pedro Alves wrote: > #2 - If you attach to a process instead of running it from GDB, then ctrl-c > reaches gdb first, and then GDB sends/forwards a SIGINT to the child process. To me this seems to be the problem. I've explicitly said I don't want the signal passed to the process under debug (not a child process in this situation right?)--in fact that's the default setting for SIGINT --but yet GDB is still passing the signal along. Isn't that incorrect behavior? Is it there just for parity between the behavior of attaching to an existing process versus running the process under GDB? I'd prefer it work one way and not the other, rather than not work either way :). In my environment I'm _always_ attaching because our processes need to be started through a separate service, or they don't have proper security tokens to join the system. So it would work OK for me if just the attached version behaved as expected. I get that others may have different needs.