Re: [PATCH v2 0/4] Improve pseudo console support.

[Takashi Yano <takashi.yano@nifty.ne.jp>]

Hi Corinna,

Thanks for testing.

On Fri, 22 Jan 2021 13:20:57 +0100
Corinna Vinschen wrote:
> Hi Takashi,
> 
> On Jan 22 05:58, Takashi Yano via Cygwin-patches wrote:
> > The new implementation of pseudo console support by commit bb428520
> > provides the important advantages, while there also has been several
> > disadvantages compared to the previous implementation.
> > 
> > These patches overturn some of them.
> > 
> > The disadvantage:
> >  1) The cygwin program which calls console API directly does not work.
> > is supposed to be able to be overcome as well, however, I am not sure
> > it is worth enough. This will need a lot of hooks for console APIs.
> > 
> > Takashi Yano (4):
> >   Cygwin: pty: Inherit typeahead data between two input pipes.
> >   Cygwin: pty: Keep code page between non-cygwin apps.
> >   Cygwin: pty: Make apps using console APIs be able to debug with gdb.
> >   Cygwin: pty: Allow multiple apps to enable pseudo console
> >     simultaneously.
> > 
> >  winsup/cygwin/fhandler.h      |  15 +-
> >  winsup/cygwin/fhandler_tty.cc | 805 ++++++++++++++++++++++++++--------
> >  winsup/cygwin/spawn.cc        | 102 +++--
> >  winsup/cygwin/tty.cc          |  11 +-
> >  winsup/cygwin/tty.h           |  18 +-
> >  5 files changed, 730 insertions(+), 221 deletions(-)
> > 
> > -- 
> > 2.30.0
> 
> I found a problem with this patchset.
> 
> Try this:
> 
>   Start mintty
> 
>   $ touch foo
>   $ attrib +r foo
>   $ gdb /bin/rm
>   $ start foo
> 
>   At this point, starting rm will take a few seconds.  While GDB is
>   still working on this, *before* GDB returns to the prompt, type some
>   keys on keyboard, e. g., "1234".
> 
> Without this patchset, you'll see the keys being echoed in mintty, and
> as soon as GDB returns to the prompt, the keys are copied to GDBs input
> buffer and the keys you typed show up after the prompt.  This is the
> expected behaviour.
> 
>   (gdb) 1234
> 
> With this patchset, the keys are *not* echoed in mintty, and as soon
> as the GDB prompt returns, the keys are still not visible.

I have fixed this issue. Please try v3 patch set. In v3 patch set,
pseudo console is not activated for GDB if the app to be debugged
is cygwin program. Also, for non-cygwin apps, I added the code to
transfer input when switching occurs between GDB and the debugging
process.

> Now continue the execution of rm:
> 
>   (gdb) c
>   /usr/bin/rm: remove write-protected regular file 'foo'? 
> 
> Without this patchset, I get
> 
>   /usr/bin/rm: error closing file
>   [...]
>   [Inferior 1 (process 1224) exited with code 01]
>   (gdb)

This seems to be a bug of cygwin GDB. The cause is that the pgid
setting for /usr/bin/rm 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.

--- inflow.c.orig	2020-05-24 06:10:29.000000000 +0900
+++ inflow.c	2021-01-23 17:48:27.963609500 +0900
@@ -364,11 +364,11 @@
 #ifdef HAVE_TERMIOS_H
 	  /* If we can't tell the inferior's actual process group,
 	     then restore whatever was the foreground pgrp the last
 	     time the inferior was running.  See also comments
 	     describing terminal_state::process_group.  */
-#ifdef HAVE_GETPGID
+#if defined (HAVE_GETPGID) && !defined (__CYGWIN__)
 	  result = tcsetpgrp (0, getpgid (inf->pid));
 #else
 	  result = tcsetpgrp (0, tinfo->process_group);
 #endif
 	  if (result == -1)


> That's not optimal, apparently.  With this patchset:
> 
>   (gdb) c
>   /usr/bin/rm: remove write-protected regular file 'foo'? 1234
> 
> so the keys typed while gdb was starting rm have been saved up and then
> used as input for rm.  That's not quite right either, is it?

Another undesired behavior of cygwin GDB is that the debugging program
in pty cannot continue to execute after interrupted by Ctrl-C. If pseudo
console is activated for the debugging program, it seems to be able to
do this for some unknown reason.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>