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