From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sa-prd-fep-043.btinternet.com (mailomta27-sa.btinternet.com [213.120.69.33]) by sourceware.org (Postfix) with ESMTPS id 833683838002 for ; Thu, 6 May 2021 20:32:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 833683838002 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dronecode.org.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=jon.turney@dronecode.org.uk Received: from sa-prd-rgout-002.btmx-prd.synchronoss.net ([10.2.38.5]) by sa-prd-fep-043.btinternet.com with ESMTP id <20210506203236.GBEZ21245.sa-prd-fep-043.btinternet.com@sa-prd-rgout-002.btmx-prd.synchronoss.net>; Thu, 6 May 2021 21:32:36 +0100 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com X-SNCR-Rigid: 6038718309BDA95C X-Originating-IP: [81.153.98.246] X-OWM-Source-IP: 81.153.98.246 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduledrvdegtddgudehudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemuceutffkvffkuffjvffgnffgvefqofdpqfgfvfenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhkffffgggjggtgfesthejredttdefjeenucfhrhhomheplfhonhcuvfhurhhnvgihuceojhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukheqnecuggftrfgrthhtvghrnhepteelffegteeiudeuteehffevledvffeffeekgffhhfehvdfhgffhteehteelteeknecuffhomhgrihhnpegthihgfihinhdrtghomhenucfkphepkedurdduheefrdelkedrvdegieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopegludelvddrudeikedruddrudduudgnpdhinhgvthepkedurdduheefrdelkedrvdegiedpmhgrihhlfhhrohhmpeeojhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukhequceuqfffjgepkeeukffvoffkoffgpdhrtghpthhtohepoegthihgfihinhestgihghifihhnrdgtohhmqedprhgtphhtthhopeeothgrkhgrshhhihdrhigrnhhosehnihhfthihrdhnvgdrjhhpqe X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.111] (81.153.98.246) by sa-prd-rgout-002.btmx-prd.synchronoss.net (5.8.340) (authenticated as jonturney@btinternet.com) id 6038718309BDA95C; Thu, 6 May 2021 21:32:36 +0100 Subject: Re: GDB looses pgrp setting in the terminal for debugged process after break. To: Takashi Yano , The Cygwin Mailing List References: <20210126121402.167ba4ca0d7d8b747feede9f@nifty.ne.jp> <20210205193457.cecc47a50865a59dc3f7041f@nifty.ne.jp> <20210206002654.17dca1106da610b2f7b7b077@nifty.ne.jp> <20210503011625.8656a8f7187120ace0e375ef@nifty.ne.jp> From: Jon Turney Message-ID: <6a422002-189a-baf8-5b65-fa822a0803a7@dronecode.org.uk> Date: Thu, 6 May 2021 21:31:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <20210503011625.8656a8f7187120ace0e375ef@nifty.ne.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1200.7 required=5.0 tests=BAYES_00, FORGED_SPF_HELO, GIT_PATCH_0, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 20:32:39 -0000 On 02/05/2021 17:16, Takashi Yano via Cygwin wrote: > On Sat, 6 Feb 2021 00:26:54 +0900 > Takashi Yano wrote: >> On Fri, 5 Feb 2021 19:34:57 +0900 >> Takashi Yano wrote: >>> On Tue, 26 Jan 2021 12:14:02 +0900 >>> Takashi Yano wrote: >>>> Hi GDB maintainer, Sorry! I meant to go back and look at this, but I forgot. Thanks for reminding me! >>>> In GDB, debugged process cannot continue execution after break >>>> if it reads stdin. >>>> >>>> With the following steps, cat is terminated with error. >>>> >>>> 1) Install coreutils-debuginfo package. >>>> 2) Run "gdb cat" in console (command prompt), not in mintty. >>>> 3) Enter "start" in gdb. >>>> 4) Enter "cont" in gdb. >>>> >>>> This results in: >>>> /usr/bin/cat: -: Input/output error >>>> >>>> Both gdb-9.2-1 and gdb-10.1-1(TEST) have this problem. >>>> >>>> I looked into this problem and found the cause is that the pgid >>>> setting for /usr/bin/cat is lost after break. The following patch >>>> for GDB source resolves the issue. In the following section, >>>> winpid is passed to getpgid() rather than cygwin pid. Also, winpid >>>> is passed to other POSIX system calls such as kill() elsewhere. >>>> [...] >>>> >>>> I hope the GDB maintainer will check it out. >>>> >>>> Addresses: https://cygwin.com/pipermail/cygwin-patches/2021q1/011018.html >>> >>> I have noticed that cygwin gdb essentially has the problem >>> regarding terminal process group. >>> >>> Cygwin gdb uses CreateProcessW() to execute debugging process Yes, being half-aware that it's using the Win32 API to do the debugging makes things awkward in gdb. At one stage, I did start writing some changes to gdb to use cygwin's fork/exec to start the inferior, rather than CreateProcess, but that's also awkward. >>> rather than exec(). If the debugging process is a cygwin process, This process is usually called the 'debugee' or 'the inferior'. >>> cygwin pid is assigned, however, if the debugging process is a >>> non cygwin process, cygwin pid is not assigned. Therefore, there >>> is no appropriate process group ID to set. I'm not sure how this scenario relates to the initial report which seems to be about a process tree: cmd -> gdb (cygwin) -> cat (cygwin) ? >>> I wonder what is the right thing under that situation. Any idea? >> >> The patch below seems to be better than the previous one a bit. >> >> diff --git a/inflow.c.orig b/inflow.c >> index 00b2235..fa7b408 100644 >> --- a/inflow.c.orig >> +++ b/inflow.c >> @@ -40,6 +40,10 @@ >> #include >> #endif >> >> +#ifdef __CYGWIN__ >> +#include >> +#endif >> + >> #ifndef O_NOCTTY >> #define O_NOCTTY 0 >> #endif >> @@ -367,7 +371,13 @@ child_terminal_inferior (struct target_ops *self) >> time the inferior was running. See also comments >> describing terminal_state::process_group. */ >> #ifdef HAVE_GETPGID >> +#ifdef __CYGWIN__ >> + pid_t cygpid = cygwin_internal (CW_WINPID_TO_CYGWIN_PID, inf->pid); >> + if (cygpid <= cygwin_internal (CW_MAX_CYGWIN_PID)) >> + result = tcsetpgrp (0, getpgid (cygpid)); >> +#else >> result = tcsetpgrp (0, getpgid (inf->pid)); >> +#endif >> #else >> result = tcsetpgrp (0, tinfo->process_group); >> #endif > > I confirmed that gdb-10.2-1 (TEST) still has this problem. It certainly seems reasonable that we need to do this cygwin/windows pid mapping somewhere.