From: Jon Turney <jon.turney@dronecode.org.uk>
To: Takashi Yano <takashi.yano@nifty.ne.jp>,
The Cygwin Mailing List <cygwin@cygwin.com>
Subject: Re: GDB looses pgrp setting in the terminal for debugged process after break.
Date: Thu, 6 May 2021 21:31:27 +0100 [thread overview]
Message-ID: <6a422002-189a-baf8-5b65-fa822a0803a7@dronecode.org.uk> (raw)
In-Reply-To: <20210503011625.8656a8f7187120ace0e375ef@nifty.ne.jp>
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 <sys/ioctl.h>
>> #endif
>>
>> +#ifdef __CYGWIN__
>> +#include <sys/cygwin.h>
>> +#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.
next prev parent reply other threads:[~2021-05-06 20:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-26 3:14 Takashi Yano
2021-02-05 10:34 ` Takashi Yano
2021-02-05 15:26 ` Takashi Yano
2021-05-02 16:16 ` Takashi Yano
2021-05-06 20:31 ` Jon Turney [this message]
2021-05-07 8:33 ` Takashi Yano
2022-01-17 18:57 ` Jon Turney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6a422002-189a-baf8-5b65-fa822a0803a7@dronecode.org.uk \
--to=jon.turney@dronecode.org.uk \
--cc=cygwin@cygwin.com \
--cc=takashi.yano@nifty.ne.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).