GDB looses pgrp setting in the terminal for debugged process after break.
Jon Turney
jon.turney@dronecode.org.uk
Thu May 6 20:31:27 GMT 2021
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.
More information about the Cygwin
mailing list