[RFC] gdb/testsuite/gdb.base/fileio.exp patch for cygwin

[RFC] gdb/testsuite/gdb.base/fileio.exp patch for cygwin

[Pierre Muller]

I tried to expose some cygwin testsuite problems
related to the fact that dejagnu does not seem
to be able to fool the cygwin system, to
get it to believe that the output is not redirected.

http://sourceware.org/ml/gdb/2007-11/msg00273.html

  The main effect is that, Cygwin knowing that 
the output is redirected to a non-tty, it will start
to use file buffering that will interact badly
with the expectation of the gdb testsuite.

  A typical example is gdb.base/fileio.exp,
because it shows both sides of what I am
describing.

  By simply adding a setbuf (stdout, NULL);
at the start of main, I reduce the number of
failures from 38 to 3.
  The three remaining failures are
the three tests for isatty function on stdin, stdout and stderr descriptors,
which are the cause of the described problem.

  As said in the referenced email, I do not know
if this is only because the cygwin port of dejagnu is old
or if it is more general.


  Is a patch like this suitable for inclusion 
in gdb testsuite? 
  If not, is there another way to try to improve
the testsuite on cygwin?


Pierre Muller

ChangeLog entry:

2007-12-02  Pierre Muller  <muller@ics.u-strasbg.fr>

	* gdb.base/fileio.c (main): Disable file buffering for Cygwin.

  
$ cvs diff -up gdb.base/fileio.c
Index: gdb.base/fileio.c
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/fileio.c,v
retrieving revision 1.10
diff -u -p -r1.10 fileio.c
--- gdb.base/fileio.c   13 Jun 2006 08:55:22 -0000      1.10
+++ gdb.base/fileio.c   3 Dec 2007 09:58:17 -0000
@@ -1,5 +1,5 @@
-#include <stdio.h>
 #include <stdlib.h>
+#include <stdio.h>
 #include <string.h>
 #include <sys/errno.h>
 #include <sys/types.h>
@@ -542,6 +542,9 @@ strerrno (int err)
 int
 main ()
 {
+#ifdef __CYGWIN__
+  setbuf (stdout, NULL);
+#endif /* __CYGWIN__ */
   /* Don't change the order of the calls.  They partly depend on each other
*/
   test_open ();
   test_write ();

Re: [RFC] gdb/testsuite/gdb.base/fileio.exp patch for cygwin

[Pedro Alves]

[-- Attachment #1: Type: text/plain, Size: 2886 bytes --]

Pierre Muller wrote:
> I tried to expose some cygwin testsuite problems
> related to the fact that dejagnu does not seem
> to be able to fool the cygwin system, to
> get it to believe that the output is not redirected.
> 
> http://sourceware.org/ml/gdb/2007-11/msg00273.html
> 
>   The main effect is that, Cygwin knowing that 
> the output is redirected to a non-tty, it will start
> to use file buffering that will interact badly
> with the expectation of the gdb testsuite.
> 

I don't think that dejagnu is to blame here, and
I believe the individual testfiles are the wrong place
to fix this.  You can easily reproduce the symptoms
in any run.  Try this with the attached patch:

#include <stdio.h>
#include <stdlib.h>

int main ()
{
         printf ("isatty 0 = %d\n", isatty (0));
         printf ("isatty 1 = %d\n", isatty (1));
         printf ("isatty 2 = %d\n", isatty (2));
         return 0;
}


--------------------

Cygwin host:

 >./main.exe
isatty 0 = 1
isatty 1 = 1
isatty 2 = 1

 >gdb main.exe
isatty (0) = 1
isatty (1) = 1
isatty (2) = 1
ttyname (0) = /dev/tty2
ttyname (1) = /dev/tty2
ttyname (2) = /dev/tty2
GNU gdb 6.7.50.20071201-cvs
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) r
Starting program: /home/pedro/isatty/main.exe
isatty 0 = 0
isatty 1 = 0
isatty 2 = 0

Program exited normally.
(gdb)


Notice the "isatty $x = 0", and contrast
with:

-------------

Linux host:

 >./main
isatty 0 = 1
isatty 1 = 1
isatty 2 = 1

 >gdb ./main
isatty (0) = 1
isatty (1) = 1
isatty (2) = 1
ttyname (0) = /dev/pts/5
ttyname (1) = /dev/pts/5
ttyname (2) = /dev/pts/5
GNU gdb 6.7.50.20071204-cvs
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) r
Starting program: /home/pedro/isatty/main
isatty 0 = 1
isatty 1 = 1
isatty 2 = 1

Program exited normally.
(gdb)

-------------

I don't know enough of the Cygwin tty support,
but I would expect that if gdb had a (Windows) console
attached (bash started from cmd.exe, not the xterm or rxvt),
the inferior would inherit it, and the runtime would arrange
for the isatty to be true, but that doesn't seem to hold.
Neither CYGWIN=tty nor 'set new-group 0' seemed to help.
This probably has something to do with starting the inferior
with CreateProcess in win32-nat.c:win32_create_inferior.

-- 
Pedro Alves


[-- Attachment #2: isatty.diff --]
[-- Type: text/x-diff, Size: 823 bytes --]

---
 gdb/main.c |    8 ++++++++
 1 file changed, 8 insertions(+)

Index: src/gdb/main.c
===================================================================
--- src.orig/gdb/main.c	2007-12-04 23:21:10.000000000 +0000
+++ src/gdb/main.c	2007-12-04 23:23:22.000000000 +0000
@@ -875,6 +875,14 @@ extern int gdbtk_test (char *);
 int
 gdb_main (struct captured_main_args *args)
 {
+  printf ("isatty (0) = %d\n", isatty (0));
+  printf ("isatty (1) = %d\n", isatty (1));
+  printf ("isatty (2) = %d\n", isatty (2));
+
+  printf ("ttyname (0) = %s\n", ttyname (0));
+  printf ("ttyname (1) = %s\n", ttyname (1));
+  printf ("ttyname (2) = %s\n", ttyname (2));
+
   use_windows = args->use_windows;
   catch_errors (captured_main, args, "", RETURN_MASK_ALL);
   /* The only way to end up here is by an error (normal exit is

RE: [RFC] gdb/testsuite/gdb.base/fileio.exp patch for cygwin

[Pierre Muller]

  I am sorry, Pedro,
but I am completely unable to reproduce
your output.
  I always get '1' as a result for all the tests
I tried running your application.
  I tried to compile the source as
gcc -g -o main.exe main.c
and in that case I got '1' for the three descriptors
in all case:
  1) run directly inside Cygwin bash
  2) run directly from cd.exe prompt (with a cygwin1.dll in the path)
  3) run inside current HEAD gdb
  4) run inside Cygwin special gdb distributed by Cygwin setup program
  5) run using gdb 6.3 for mingw32

If I add -mno-cygwin, I get '64' as a result instead of '1'
for all three descriptors, but then again
running the executable directly or within any of the gdb mentioned above
gives always '64'.



> -----Original Message-----
> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] On Behalf Of Pedro Alves
> Sent: Wednesday, December 05, 2007 12:50 AM
> To: Pierre Muller
> Cc: gdb-patches@sourceware.org
> Subject: Re: [RFC] gdb/testsuite/gdb.base/fileio.exp patch for cygwin
> 
> Pierre Muller wrote:
> > I tried to expose some cygwin testsuite problems related to the fact
> > that dejagnu does not seem to be able to fool the cygwin system, to
> > get it to believe that the output is not redirected.
> >
> > http://sourceware.org/ml/gdb/2007-11/msg00273.html
> >
> >   The main effect is that, Cygwin knowing that the output is
> > redirected to a non-tty, it will start to use file buffering that
> will
> > interact badly with the expectation of the gdb testsuite.
> >
> 
> I don't think that dejagnu is to blame here, and
> I believe the individual testfiles are the wrong place
> to fix this.  You can easily reproduce the symptoms
> in any run.  Try this with the attached patch:
> 
> #include <stdio.h>
> #include <stdlib.h>
> 
> int main ()
> {
>          printf ("isatty 0 = %d\n", isatty (0));
>          printf ("isatty 1 = %d\n", isatty (1));
>          printf ("isatty 2 = %d\n", isatty (2));
>          return 0;
> }

  How did you compile that source exactly?
> --------------------
> 
> Cygwin host:
> 
>  >./main.exe
> isatty 0 = 1
> isatty 1 = 1
> isatty 2 = 1
 Is this a cmd.exe prompt?

>  >gdb main.exe
> isatty (0) = 1
> isatty (1) = 1
> isatty (2) = 1
> ttyname (0) = /dev/tty2
> ttyname (1) = /dev/tty2
> ttyname (2) = /dev/tty2
  From where is this coming from?

> GNU gdb 6.7.50.20071201-cvs
> Copyright (C) 2007 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "i686-pc-cygwin"...
> (gdb) r
> Starting program: /home/pedro/isatty/main.exe
> isatty 0 = 0
> isatty 1 = 0
> isatty 2 = 0

   As said above, I never get this...

Pierre

Re: [RFC] gdb/testsuite/gdb.base/fileio.exp patch for cygwin

[Pedro Alves]

Pierre Muller wrote:
>   I am sorry, Pedro,
> but I am completely unable to reproduce
> your output.
>   I always get '1' as a result for all the tests
> I tried running your application.

Blurfh.  I first tried doing a make check with the
patch I attached on my previous message, and with a
hacked fileio.c to see what gdb and the inferior
stdin/out/err streams were.  The result is something like:

(output a bit different from the previous patch to
  make it clearer what is what)

make check RUNTESTFLAGS="--target_board=cygwin fileio.exp"

(...)
spawn
/cygdrive/d/cegccsf/cegcc/cegcc/src/build-gdb_server_cygwin_submit/gdb/testsuite/../../gdb/gdb 

-nw -nx
gdb: isatty (0) = 1, ttyname (0) = /dev/tty1
gdb: isatty (1) = 1, ttyname (1) = /dev/tty1
gdb: isatty (2) = 1, ttyname (2) = /dev/tty1
GNU gdb 6.7.50.20071201-cvs
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin".

(...)

(gdb) run
Starting program:
/cygdrive/d/cegccsf/cegcc/cegcc/src/build-gdb_server_cygwin_submit/gdb/testsuite/gdb.base/fileio.exe 



Breakpoint 1, main () at
../../../gdb-server_submit/src/gdb/testsuite/gdb.base/fileio.c:546
546	  for (i = 0; i < 3; i++)
(gdb) break stop
Breakpoint 2: file
../../../gdb-server_submit/src/gdb/testsuite/gdb.base/fileio.c, line 71.
(gdb) continue
Continuing.
inf: isatty (0) = 0, ttyname (0) = (null)
inf: isatty (1) = 0, ttyname (1) = (null)
inf: isatty (2) = 0, ttyname (2) = (null)

Seeing this, I tried the example standalone/non-dejagnu
test I posted, but with CYGWIN=tty, which produces the
exact same results dejagnu sees.

I then removed 'tty' from CYGWIN, but failed to
restart every cygwin process, which made me fail to
see what you saw.  Which shows:

>gdb ./main.exe
gdb: isatty (0) = 1, ttyname (0) = /dev/console
gdb: isatty (1) = 1, ttyname (1) = /dev/console
gdb: isatty (2) = 1, ttyname (2) = /dev/console
GNU gdb 6.7.50.20071201-cvs
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) r
Starting program: /home/pedro/isatty/main.exe
inf: isatty (0) = 1, ttyname (0) = /dev/console
inf: isatty (1) = 1, ttyname (1) = /dev/console
inf: isatty (2) = 1, ttyname (2) = /dev/console

Program exited normally.
(gdb)

Which is the behaviour I was expecting:
  "I don't know enough of the Cygwin tty support,
  but I would expect that if gdb had a (Windows) console
  attached (bash started from cmd.exe, not the xterm or rxvt),
  the inferior would inherit it, and the runtime would arrange
  for the isatty to be true, but that doesn't seem to hold."

Sorry for the confusion.

So, the excelent description Corinna posted applies
to the dejagnu case here.

-- 
Pedro Alves

Re: [RFC] gdb/testsuite/gdb.base/fileio.exp patch for cygwin

[Corinna Vinschen]

On Dec  4 23:49, Pedro Alves wrote:
> #include <stdio.h>
> #include <stdlib.h>
>
> int main ()
> {
>         printf ("isatty 0 = %d\n", isatty (0));
>         printf ("isatty 1 = %d\n", isatty (1));
>         printf ("isatty 2 = %d\n", isatty (2));
>         return 0;
> }
> [...]
> This GDB was configured as "i686-pc-cygwin"...
> (gdb) r
> Starting program: /home/pedro/isatty/main.exe
> isatty 0 = 0
> isatty 1 = 0
> isatty 2 = 0
> [...]
> I don't know enough of the Cygwin tty support,
> but I would expect that if gdb had a (Windows) console
> attached (bash started from cmd.exe, not the xterm or rxvt),
> the inferior would inherit it, and the runtime would arrange
> for the isatty to be true, but that doesn't seem to hold.
> Neither CYGWIN=tty nor 'set new-group 0' seemed to help.
> This probably has something to do with starting the inferior
> with CreateProcess in win32-nat.c:win32_create_inferior.

Right.  The problem occurs when running a session in a pseudo tty like
when starting GDB in a ssh session or when you set CYGWIN=tty before
starting the first Cygwin process (the shell, usually) in a Windows
console window.

Pseudo ttys are implemented in Cygwin using pipes.  When you start a
Cygwin application with fork/exec, the knowledge about this pipes (being
a pseudo tty) is inherited by the child process by means of the fork/
exec magic.

If you start a Cygwin process from another application using native
Windows functions (CreateProcess, etc), the whole fork/exec magic is
missing, apparently.  One result is that the child process has to
figure out what the stdin/out/err streams are, using native Windows
functions.  Since native Windows functions have no idea what a pseudo
tty is, the information returned is that stdio streams are connected
to pipes.  So the child thinks its stdio streams are just pipes and
pipes are not ttys, apparently.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

Re: [RFC] gdb/testsuite/gdb.base/fileio.exp patch for cygwin

[Eli Zaretskii]

> Date: Wed, 5 Dec 2007 11:11:09 +0100
> From: Corinna Vinschen <vinschen@redhat.com>
> 
> If you start a Cygwin process from another application using native
> Windows functions (CreateProcess, etc), the whole fork/exec magic is
> missing, apparently.  One result is that the child process has to
> figure out what the stdin/out/err streams are, using native Windows
> functions.  Since native Windows functions have no idea what a pseudo
> tty is, the information returned is that stdio streams are connected
> to pipes.  So the child thinks its stdio streams are just pipes and
> pipes are not ttys, apparently.

I don't know if this is relevant (probably not), but please note that
native Windows implementation of `isatty' does not faithfully emulates
Posix functionality: it returns non-zero on _any_character_device_,
not just on a terminal.  For example, try redirecting to/from the null
device.

My grabbag of workarounds for Windows gotcha's includes this:

   #define ISATTY(fd) (isatty(fd) && lseek(fd,SEEK_CUR,0) == -1)

Re: [RFC] gdb/testsuite/gdb.base/fileio.exp patch for cygwin

[Pedro Alves]

Corinna Vinschen wrote:
> 
> Right.  The problem occurs when running a session in a pseudo tty like
> when starting GDB in a ssh session or when you set CYGWIN=tty before
> starting the first Cygwin process (the shell, usually) in a Windows
> console window.
> 
> Pseudo ttys are implemented in Cygwin using pipes.  When you start a
> Cygwin application with fork/exec, the knowledge about this pipes (being
> a pseudo tty) is inherited by the child process by means of the fork/
> exec magic.
> 
> If you start a Cygwin process from another application using native
> Windows functions (CreateProcess, etc), the whole fork/exec magic is
> missing, apparently.  One result is that the child process has to
> figure out what the stdin/out/err streams are, using native Windows
> functions.  Since native Windows functions have no idea what a pseudo
> tty is, the information returned is that stdio streams are connected
> to pipes.  So the child thinks its stdio streams are just pipes and
> pipes are not ttys, apparently.
> 
> 

Thank you very much for the explanation.

Isn't there a shared memory section amongst all loaded
copies of cygwin1.dll?  Can't that be used to reconstruct
the pseudo ttys from the pipes?

-- 
Pedro Alves

Re: [RFC] gdb/testsuite/gdb.base/fileio.exp patch for cygwin

[Daniel Jacobowitz]

On Wed, Dec 05, 2007 at 10:56:21PM +0000, Pedro Alves wrote:
> Isn't there a shared memory section amongst all loaded
> copies of cygwin1.dll?  Can't that be used to reconstruct
> the pseudo ttys from the pipes?

I might be mistaken, but I don't think there's any way to figure out
the original identity of the pipe.  Handles aren't globally unique,
are they?

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] gdb/testsuite/gdb.base/fileio.exp patch for cygwin

[Pedro Alves]

Daniel Jacobowitz wrote:

> I might be mistaken, but I don't think there's any way to figure out
> the original identity of the pipe.  Handles aren't globally unique,
> are they?
>

Yeah, I keep thinking CE, where they *are* global.

There may be other ways to identify the pipes, like using
named pipes for the ttys if possible -- but I don't know if
it's possible to get a pipe name from a pipe handle.  If
there's a way to know if two handles point to the same
object it should work too, but I don't think that's possible either...

-- 
Pedro Alves

Re: [RFC] gdb/testsuite/gdb.base/fileio.exp patch for cygwin

[Pedro Alves]

Pedro Alves wrote:
> Daniel Jacobowitz wrote:
>
> > I might be mistaken, but I don't think there's any way to figure out
> > the original identity of the pipe.  Handles aren't globally unique,
> > are they?
> >
>
> Yeah, I keep thinking CE, where they *are* global.
>
> There may be other ways to identify the pipes, like using
> named pipes for the ttys if possible -- but I don't know if
> it's possible to get a pipe name from a pipe handle.  If
> there's a way to know if two handles point to the same
> object it should work too, but I don't think that's possible either...
>

Just for completeness:

Been googling a bit, and, as the Cygwin folks sure know,
under NT it is possible to get the internal names of objects,
and NT assigns unique names to pipes.

This is from the test files pasted at the bottom:

>./parent.exe
par: Filename from handle (STD_INPUT_HANDLE) returned :
\Device\NamedPipe\Win32Pipes.00000c70.00000002
par: Filename from handle (STD_OUTPUT_HANDLE) returned :
\Device\NamedPipe\Win32Pipes.00000c70.00000003
par: Filename from handle (STD_ERROR_HANDLE) returned :
\Device\NamedPipe\Win32Pipes.00000c70.00000003
par: Filename from handle (hReadPipe) returned :
\Device\NamedPipe\Win32Pipes.00000290.00000002
par: Filename from handle (hWritePipe) returned :
\Device\NamedPipe\Win32Pipes.00000290.00000002
par: Filename from handle (h) returned :
\Device\NamedPipe\testpipe
par: Filename from handle (duph) returned :
\Device\NamedPipe\Win32Pipes.00000290.00000002
child: Filename from handle (STD_INPUT_HANDLE) returned :
\Device\NamedPipe\Win32Pipes.00000c70.00000002
child: Filename from handle (STD_OUTPUT_HANDLE) returned :
\Device\NamedPipe\Win32Pipes.00000c70.00000003
child: Filename from handle (STD_ERROR_HANDLE) returned :
\Device\NamedPipe\Win32Pipes.00000c70.00000003

Notice that the STD_{INPUT|OUTPUT|ERROR}_HANDLEs are the
same pipes.

Since the next big Cygwin release will be NT only, perhaps this could
be used to map pipes to ttys.

Disclosure: I haven't really looked into Cygwin's sources to see
what it would take.  It may be saying something plain dumb.

-- 
Pedro Alves


parent.c:

#include <stdio.h>
#include <windows.h>

typedef struct _UNICODE_STRING {
    USHORT Length;
    USHORT MaximumLength;
    PWSTR  Buffer;
} UNICODE_STRING;
typedef UNICODE_STRING *PUNICODE_STRING;

#define STATUS_SUCCESS 0
typedef ULONG NTSTATUS;

typedef enum _OBJECT_INFO_CLASS {
    ObjectBasicInfo,
    ObjectNameInfo,
    ObjectTypeInfo,
    ObjectAllTypesInfo,
    ObjectProtectionInfo
} OBJECT_INFO_CLASS;

typedef NTSTATUS (NTAPI * NTQUERYOBJECT)(HANDLE, OBJECT_INFO_CLASS,
					 PVOID, ULONG, PULONG);

typedef struct ObjectNameInfo_t {
    UNICODE_STRING ObjectName;
    WCHAR ObjectNameBuffer[1];
} OBJECT_NAME_INFO, *POBJECT_NAME_INFO;

static BOOL
print_object_name (const char *var, HANDLE h)
{
  HMODULE ntdll = GetModuleHandle ("ntdll.dll");
  NTQUERYOBJECT NtQueryObject
    = (NTQUERYOBJECT) GetProcAddress (ntdll, "NtQueryObject");

  char buf1[1024];
  char buf2[1024];

  POBJECT_NAME_INFO pObjectNameInfo = (POBJECT_NAME_INFO) buf1;

  int rc = NtQueryObject (h, ObjectNameInfo, buf1, sizeof (buf1), NULL);
  if (rc != STATUS_SUCCESS)
    {
      printf ("NtQueryObject failed with rc = 0x%x\n",  rc);
      return FALSE;
    }

  wcstombs (buf2, pObjectNameInfo->ObjectName.Buffer, 1024);
  printf ("par: Filename from handle (%s) returned :\n%s\n", var, buf2);
  return 0;
}

int
main (int argc, char **argv)
{
  print_object_name ("STD_INPUT_HANDLE", GetStdHandle (STD_INPUT_HANDLE));
  print_object_name ("STD_OUTPUT_HANDLE", GetStdHandle (STD_OUTPUT_HANDLE));
  print_object_name ("STD_ERROR_HANDLE", GetStdHandle (STD_ERROR_HANDLE));

  DWORD bufferSize = 1024;

  HANDLE h = CreateNamedPipe ("\\\\.\\pipe\\testpipe",
			      PIPE_ACCESS_DUPLEX,
			      PIPE_TYPE_BYTE,
			      PIPE_UNLIMITED_INSTANCES,
			      bufferSize,
			      bufferSize,
			      1,
			      NULL);

  if (h == INVALID_HANDLE_VALUE)
  {
    printf ("CreateNamedPipe failed\n");
    return 1;
  }

  HANDLE hReadPipe;
  HANDLE hWritePipe;
  BOOL good = CreatePipe (&hReadPipe, &hWritePipe, NULL, 100);
  if (!good)
  {
    printf ("CreatePipe failed\n");
    return 1;
  }

  print_object_name ("hReadPipe", hReadPipe);
  print_object_name ("hWritePipe", hWritePipe);
  print_object_name ("h", h);

  HANDLE duph = INVALID_HANDLE_VALUE;
  if (!DuplicateHandle (GetCurrentProcess(),
			hReadPipe,
			GetCurrentProcess(),
			&duph,
			0,
			TRUE,
			DUPLICATE_SAME_ACCESS))
    {
      printf ("DuplicateHandle failed\n");
      return 1;
    }

  print_object_name ("duph", duph);

  PROCESS_INFORMATION pi;

  STARTUPINFO si;
  memset (&si, 0, sizeof (si));
  si.cb = sizeof (si);

  CreateProcess (0,
		 "child.exe",/* command line */
		 NULL,	/* Security */
		 NULL,	/* thread */
		 TRUE,	/* inherit handles */
		 0,	/* start flags */
		 NULL,	/* environment */
		 NULL,	/* current directory */
		 &si,
		 &pi);

  return 0;
}

---------
child.c:

#include <stdio.h>
#include <windows.h>

typedef struct _UNICODE_STRING {
    USHORT Length;
    USHORT MaximumLength;
    PWSTR  Buffer;
} UNICODE_STRING;
typedef UNICODE_STRING *PUNICODE_STRING;

#define STATUS_SUCCESS 0
typedef ULONG NTSTATUS;

typedef enum _OBJECT_INFO_CLASS {
    ObjectBasicInfo,
    ObjectNameInfo,
    ObjectTypeInfo,
    ObjectAllTypesInfo,
    ObjectProtectionInfo
} OBJECT_INFO_CLASS;

typedef NTSTATUS (NTAPI * NTQUERYOBJECT)(HANDLE, OBJECT_INFO_CLASS,
					 PVOID, ULONG, PULONG);

typedef struct ObjectNameInfo_t {
    UNICODE_STRING ObjectName;
    WCHAR ObjectNameBuffer[1];
} OBJECT_NAME_INFO, *POBJECT_NAME_INFO;

static BOOL
print_object_name (const char *var, HANDLE h)
{
  HMODULE ntdll = GetModuleHandle ("ntdll.dll");
  NTQUERYOBJECT NtQueryObject
    = (NTQUERYOBJECT) GetProcAddress (ntdll, "NtQueryObject");

  char buf1[1024];
  char buf2[1024];

  POBJECT_NAME_INFO pObjectNameInfo = (POBJECT_NAME_INFO) buf1;

  int rc = NtQueryObject (h, ObjectNameInfo, buf1, sizeof (buf1), NULL);
  if (rc != STATUS_SUCCESS)
    {
      printf ("NtQueryObject failed with rc = 0x%x\n",  rc);
      return FALSE;
    }

  wcstombs (buf2, pObjectNameInfo->ObjectName.Buffer, 1024);
  printf ("child: Filename from handle (%s) returned :\n%s\n", var, buf2);
  return 0;
}

int
main (int argc, char **argv)
{
  print_object_name ("STD_INPUT_HANDLE", GetStdHandle (STD_INPUT_HANDLE));
  print_object_name ("STD_OUTPUT_HANDLE", GetStdHandle (STD_OUTPUT_HANDLE));
  print_object_name ("STD_ERROR_HANDLE", GetStdHandle (STD_ERROR_HANDLE));

  return 0;
}

Re: [RFC] gdb/testsuite/gdb.base/fileio.exp patch for cygwin

[Corinna Vinschen]

On Dec  6 03:42, Pedro Alves wrote:
> Pedro Alves wrote:
> > Daniel Jacobowitz wrote:
> > > I might be mistaken, but I don't think there's any way to figure out
> > > the original identity of the pipe.
> >
> > There may be other ways to identify the pipes, like using
> > named pipes for the ttys if possible -- but I don't know if
> > it's possible to get a pipe name from a pipe handle.
> 
> Been googling a bit, and, as the Cygwin folks sure know,
> under NT it is possible to get the internal names of objects,
> and NT assigns unique names to pipes.

It does up to Windows 2003 Server.  On Vista, anonymous pipes are really
anonymous and you can't retrieve a name anymore.

> Since the next big Cygwin release will be NT only, perhaps this could
> be used to map pipes to ttys.
> 
> Disclosure: I haven't really looked into Cygwin's sources to see
> what it would take.  It may be saying something plain dumb.

It requires to switch to named pipes due to Vista.  And you're still
missing any tty settings afterwards, you just have a naked handle to
start over with.  This is not on my TODO list for the next major version,
but patches are of course welcome!


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

Re: [RFC] gdb/testsuite/gdb.base/fileio.exp patch for cygwin

[Christopher Faylor]

On Thu, Dec 06, 2007 at 10:23:32AM +0100, Corinna Vinschen wrote:
>On Dec  6 03:42, Pedro Alves wrote:
>> Pedro Alves wrote:
>> > Daniel Jacobowitz wrote:
>> > > I might be mistaken, but I don't think there's any way to figure out
>> > > the original identity of the pipe.
>> >
>> > There may be other ways to identify the pipes, like using
>> > named pipes for the ttys if possible -- but I don't know if
>> > it's possible to get a pipe name from a pipe handle.
>> 
>> Been googling a bit, and, as the Cygwin folks sure know,
>> under NT it is possible to get the internal names of objects,
>> and NT assigns unique names to pipes.
>
>It does up to Windows 2003 Server.  On Vista, anonymous pipes are really
>anonymous and you can't retrieve a name anymore.
>
>> Since the next big Cygwin release will be NT only, perhaps this could
>> be used to map pipes to ttys.
>> 
>> Disclosure: I haven't really looked into Cygwin's sources to see
>> what it would take.  It may be saying something plain dumb.
>
>It requires to switch to named pipes due to Vista.  And you're still
>missing any tty settings afterwards, you just have a naked handle to
>start over with.  This is not on my TODO list for the next major version,
>but patches are of course welcome!

Fixing ttys is on my todo list, so there may be some hope there.

cgf