From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127230 invoked by alias); 19 May 2016 16:01:14 -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 127215 invoked by uid 89); 19 May 2016 16:01:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No 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=H*F:D*mozilla.com, filed, hear, desire X-HELO: mail-yw0-f178.google.com Received: from mail-yw0-f178.google.com (HELO mail-yw0-f178.google.com) (209.85.161.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 19 May 2016 16:01:03 +0000 Received: by mail-yw0-f178.google.com with SMTP id g133so82594800ywb.2 for ; Thu, 19 May 2016 09:01:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=58tVolOuarS6L3fZGJLRJn9Ro6/fzJE+NV7qiWU7sMk=; b=Xbva74qsko8Y8o5mo27648U9o/iSV3SpkI9torTvFZf+gYOTa5h4RHxi0cN/nO06Id UngD6c6eCyQicuGBMVocACqUesAo24DvwJJblbdfGfv3fnz3EBpVu/M4lPfjzOIrg7jp KGEhkSEfhumdqk3cQ4hEDk/HNROoH+AJbONNbwovKD9WvVrDXJmrfTEDOPuXhTWqX43k 3ivUSuUnTZNqv7F5ej6DWQhOIGVn1JML2ZlwP0cNtbDoPrACJKJ6X22yRoNqWFbO1xw/ rEZpFbsm2YAdD4rwHlG4pTEkUX7A1wK6myqwNUrLGSu2/mEjx3zgd947pywaUCG+fuVQ ijBw== X-Gm-Message-State: AOPr4FXXhHKYC6RAofUSGOrwINBVTee6SBGrCqqJRiTNWAn4jxG8hQngfRvHfqP65OFUisxO X-Received: by 10.37.223.205 with SMTP id w196mr7547043ybg.122.1463673661534; Thu, 19 May 2016 09:01:01 -0700 (PDT) Received: from [192.168.100.118] ([208.102.166.82]) by smtp.googlemail.com with ESMTPSA id m141sm8565327ywd.2.2016.05.19.09.01.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 May 2016 09:01:00 -0700 (PDT) Subject: Re: [PATCH] [GDBServer] Send SIGINT using process group ID To: Pedro Alves , gdb-patches@sourceware.org References: <1463003507-13094-1-git-send-email-nchen@mozilla.com> <1463003507-13094-2-git-send-email-nchen@mozilla.com> From: Jim Chen Message-ID: <562afb38-a633-95c1-5b49-cf2e02454edb@mozilla.com> Date: Thu, 19 May 2016 16:01:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:49.0) Gecko/20100101 Thunderbird/49.0a1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-05/txt/msg00340.txt.bz2 The use case was attaching, like you mentioned, on Android. And I just found PR/18945 [1], which describes the problem. I now see that my patch is not a good solution either because on Android, the pgid is the zygote process, and all running apps on the system belong to that group. Seems like the best solution is to handle attaching separately? Or maybe send SIGINT to the process first, and if that fails, send it to the process group, in order to address the original bug of a dead main thread when pausing? Thanks, Jim [1] https://sourceware.org/bugzilla/show_bug.cgi?id=18945 On 5/18/2016 8:10 AM, Pedro Alves wrote: > On 05/11/2016 10:51 PM, Jim Chen wrote: >> Hi, >> >> linux_request_interrupt is supposed to send SIGINT to the process group, >> but it passes the process ID to kill() instead of the process group ID, >> which may not be the same as the process ID. >> The patch calls getpgid >> first to get the process group ID. >> >> Patch tested on arm-linux. > > Can you expand on the use case you see this happening on, please? > I can imagine some, but I'd like to hear it from you. > > Some have expressed desire to _not_ send the SIGINT to the whole > process group, which may make sense when you're attached to a > process rather than having started it. IIRC, there's a bug filed in > bugzilla about this. > > Looking at the code, not-sending-to-process-group-when-attached > is what native GNU/Linux does too (inflow.c:pass_signal). > > Seems like "c&" -> "interrupt" doesn't consider "attach" either, > as inf-ptrace.c:inf_ptrace_interrupt sends the SIGINT > to the process, and like gdbserver, assumes the inferior's > PID is the process group id. > > Thanks, > Pedro Alves >