Re: cin and read(*,*) not waiting for kbd input in gdb

[Jon Turney]

On 28/01/2020 15:40, Rockefeller, Harry wrote:

Since you and I appear to be the only ones interested in this particular 
problem I brought this off the
Cygwin list, at least for now.


Please don't do this.

https://cygwin.com/problems.html#personal-email


You are correct, and I am able to reproduce this myself as well using gdb 
8.1.1-1.
In gdb 8.1.1-1 here is the same test case with stdin running correctly using a continue 
after the breakpoint that caused the gdb internal error before. > Thread 1 
"test1" hit Breakpoint 1, test1 () at test1.f:9
9read(*,*) cycle_length
Breakpoint 2 at 0x3df9bb3e0: file 
/usr/src/debug/gcc-7.4.0-1/libgfortran/io/unix.c, line 277.
(gdb) c
Continuing.

Thread 1 "test1" hit Breakpoint 2, _gfortrani_flush_if_preconnected 
(s=0x80004e300) at /usr/src/debug/gcc-7.4.0-1/libgfortran/io/unix.c:277
277 fflush (stdin);
(gdb) c
Continuing.
-1
STOP normal termination
[Thread 8904.0x2f34 exited with code 0]
[Thread 8904.0x1e78 exited with code 0]
[Inferior 1 (process 8904) exited normally]
(gdb)

Now, reloading gdb 8.2.1-1:


Again, I don't seem to be able to reproduce this:


$ gdb ./test1
GNU gdb (GDB) (Cygwin 8.2.1-1) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
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 "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./test1...done.
(gdb) b test1.f:9
Breakpoint 1 at 0x100401140: file test1.f, line 9.
(gdb) r
Starting program: /wip/test1
 Supply the equivalent of run time in seconds.
(Note: a negative run time will stop run):
Thread 1 "test1" hit Breakpoint 1, test () at test1.f:9
9   read(*,*) cycle_length
(gdb) b unix.c:271
Breakpoint 2 at 0x3e11eb3c0: file 
/usr/src/debug/gcc-7.4.0-1/libgfortran/io/unix.c, line 272.
(gdb) c
Continuing.

Thread 1 "test1" hit Breakpoint 2, _gfortrani_flush_if_preconnected 
(s=0x80003b160) at /usr/src/debug/gcc-7.4.0-1/libgfo
rtran/io/unix.c:272
272 {
(gdb) c
Continuing.
-1
STOP normal termination
[Inferior 1 (process 10024) exited normally]
(gdb)



The only thing changed was the gdb version.  I don't know how to proceed from 
here.
Can you tell if this is a gdb or a "Cygwin implementation of" gdb problem?


I'm not sure what the distinction you are making here is?  The problem 
almost certainly exists in upstream gdb, without the few patches which 
are applied in the Cygwin package of gdb.


I'd guess that this is problem is due to upstream changes in gdb, 
interacting with bugs or limitations of Cygwin.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: cin and read(*,*) not waiting for kbd input in gdb

[Jon Turney]

On 27/01/2020 16:44, Rockefeller, Harry wrote:

I don't know if this is a gdb or a Cygwin implementation of gdb that is a 
problem.
Since I can go back to gdb version 8.1.1-1 this is not a problem for me now.
Here is a test case using the Fortran source above:

$ gfortran -g test1.f -o test1.exe

harryr@HARRYR-PC ~/d62sim/Excel
$ gdb test1
GNU gdb (GDB) (Cygwin 8.3.1-1) 8.3.1

[...]

(gdb)
277 fflush (stdin);
(gdb)
/wip/cygport-git/gdb/gdb-8.3.1-1.x86_64/src/gdb-8.3.1/gdb/infrun.c:2602: 
internal-error: void resume_1(gdb_signal): Assertion `pc_in_thread_step_range 
(pc, tp)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)y


Thanks for reporting this problem, and the reproduction steps.

I can reproduce this, but this doesn't seem to be a regression as I can 
also reproduce it with 8.1.1-1 (and with 7.9.1-1).


On a brief investigation this seems to be related to trying to step 
through an import stub.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: cin and read(*,*) not waiting for kbd input in gdb

[Rockefeller, Harry]

[snip]
>>>I'm not able to reproduce this problem.  Perhaps you can provide a similar 
>>>transcript showing the steps to reproduce?
[snip]
>>Test code:
 > >program test
  >>implicit none
   >>   realcycle_time_preset /0.0/ ! (seconds)
>>  realcycle_length /0.0/  ! (seconds)
 >> do
  >>   if (cycle_time_preset.le.0.0) then
   >> write(*,*)'Supply the equivalent of run time in seconds.'
>>write(*,"('(Note: a negative run time will stop run): ',$)")
 >>   read(*,*) cycle_length
 >>else
  >>  cycle_length = cycle_time_preset
 >>end if
 >>if (cycle_length .lt. 0.0) stop 'normal termination'
  >>end do
  >>stop
  >>end

>>$ /usr/bin/gfortran   -g -ffree-form -ffree-line-length-none -Wunused 
>>-ffpe-trap=invalid,zero,overflow -o test.exe test.f
[snip]
>Following your test I do not have cin wait for kbd input whenever a breakpoint 
>is set.
>In fact, if I run 'disa 1' to disable the breakpoint and then just 'run'
>(to restart the program from the beginning) then the program does pause for my 
>keyboard input.
>This happens in both my Win 7 and Win 7 - RTX OS boots.
>This happens in both gdb 8.2.1-1 and 8.3.1-1.  It does not happen with Gdb 
>version 8.1.1-1.
[snip]

I don't know if this is a gdb or a Cygwin implementation of gdb that is a 
problem.
Since I can go back to gdb version 8.1.1-1 this is not a problem for me now.
Here is a test case using the Fortran source above:

$ gfortran -g test1.f -o test1.exe

harryr@HARRYR-PC ~/d62sim/Excel
$ gdb test1
GNU gdb (GDB) (Cygwin 8.3.1-1) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
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 "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from test1...
(gdb) b test1.f:9
Breakpoint 1 at 0x100401140: file test1.f, line 9.
(gdb) r
Starting program: /cygdrive/c/Users/harryr/d62sim/Excel/test1
[New Thread 7696.0x2a9c]
[New Thread 7696.0xf0c]
[New Thread 7696.0x22f8]
 Supply the equivalent of real time test in seconds.
(Note: a negative test length will stop run):
Thread 1 "test1" hit Breakpoint 1, test1 () at test1.f:9
9read(*,*) cycle_length
(gdb) b unix.c:271
Breakpoint 2 at 0x3df9bb3c0: file 
/usr/src/debug/gcc-7.4.0-1/libgfortran/io/unix.c, line 272.
(gdb) c
Continuing.

Thread 1 "test1" hit Breakpoint 2, _gfortrani_flush_if_preconnected 
(s=0x80004e300) at /usr/src/debug/gcc-7.4.0-1/libgfortran/io/unix.c:272
272 {
(gdb) s
275   fd = ((unix_stream *) s)->fd;
(gdb)
276   if (fd == STDIN_FILENO)
(gdb)
277 fflush (stdin);
(gdb)
__getreent () at /usr/src/debug/cygwin-3.1.2-1/winsup/cygwin/thread.cc:89
89return &_my_tls.local_clib;
(gdb)
NtCurrentTeb () at /usr/src/debug/cygwin-3.1.2-1/winsup/cygwin/thread.cc:89
89return &_my_tls.local_clib;
(gdb)
__readgsqword (Offset=48) at 
/usr/x86_64-pc-cygwin/sys-root/usr/include/w32api/psdk_inc/intrin-impl.h:714
714 
/usr/x86_64-pc-cygwin/sys-root/usr/include/w32api/psdk_inc/intrin-impl.h: No 
such file or directory.
(gdb)
__getreent () at /usr/src/debug/cygwin-3.1.2-1/winsup/cygwin/thread.cc:89
89return &_my_tls.local_clib;
(gdb)
90  }
(gdb)
_gfortrani_flush_if_preconnected (s=) at 
/usr/src/debug/gcc-7.4.0-1/libgfortran/io/unix.c:282
282 }
(gdb)
277 fflush (stdin);
(gdb)
/wip/cygport-git/gdb/gdb-8.3.1-1.x86_64/src/gdb-8.3.1/gdb/infrun.c:2602: 
internal-error: void resume_1(gdb_signal): Assertion `pc_in_thread_step_range 
(pc, tp)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)y

This is a bug, please report it.  For instructions, see:
.

/wip/cygport-git/gdb/gdb-8.3.1-1.x86_64/src/gdb-8.3.1/gdb/infrun.c:2602: 
internal-error: void resume_1(gdb_signal): Assertion `pc_in_thread_step_range 
(pc, tp)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) y
Aborted (core dumped)



gdb.exe.stackdump
Description: gdb.exe.stackdump

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: cin and read(*,*) not waiting for kbd input in gdb

[Rockefeller, Harry]

>-Original Message-
> From: cygwin-ow...@cygwin.com  On Behalf Of 
> Rockefeller, Harry
>Sent: Friday, January 17, 2020 11:35 AM
>To: Jon Turney ; The Cygwin Mailing List 
>
>Subject: RE: cin and read(*,*) not waiting for kbd input in gdb

>>>-Original Message-
>>>From: Jon Turney 
>>Sent: Friday, January 17, 2020 9:40 AM
>>To: The Cygwin Mailing List 
>>Cc: Rockefeller, Harry 
>>Subject: Re: cin and read(*,*) not waiting for kbd input in gdb
>>EXTERNAL EMAIL: STOP and verify sender address, links, and attachments before 
>>taking action.
>>On 16/01/2020 21:02, Rockefeller, Harry wrote:
>>> Both the Fortran and cpp used to work correctly when run in gdb.
>>
>>Thanks for reporting this problem.
>>
>>I assume this means that this worked with gdb-8.1.1-1, but not with
>>gdb-8.2.1-1 (Made available for testing 2019-03-21 [1], promoted to
>>current 2020-01-07 [2])
>>
>>Firstly, can I suggest that if a working gdb is important to you, you try 
>>test versions when they are available.  Wider testing helps me make good 
>>releases of gdb.
>>Secondly, can you try the recently made test release of gdb-8.3.1-1 [3], to 
>>see if this behaves differently?  If that doesn't help, you can downgrade to 
>>8.1.1-1 for the moment...

>I certainly plan to do that as soon as problem(s) are identified.

>>[1] https://cygwin.com/ml/cygwin-announce/2019-03/msg00032.html
>>[2] https://cygwin.com/ml/cygwin/2020-01/msg00064.html
>>[3] https://cygwin.com/ml/cygwin-announce/2019-12/msg00033.html
>>
>>> FWIW, Both Fortran and cpp work correctly, stopping for keyboard input, 
>>> when run outside of gdb.
>>>
>>> But now, code simply doesn't stop to take keyboard input inside gdb.
>>>
>>> [C++ test code omitted for brevity]

>>I'm not able to reproduce this problem.  Perhaps you can provide a similar 
>>transcript showing the steps to reproduce?

>I see that when I ran it I also had a few lines like these:
>[New Thread 6188.0x1e54].
>Since I develop mostly for "hard" real time, my default boot is a Win7 with 
>RTX.
>I rebooted my pc with the Win7 alone (no RTX) and the stdin does work as you 
>show below.
>I am working with my software support staff to find out if anything changed 
>recently in my PC boot stuff.

>>> $ gdb rockefeller.exe
>>> GNU gdb (GDB) (Cygwin 8.2.1-1) 8.2.1
>>> Copyright (C) 2018 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 "x86_64-pc-cygwin".
>>> Type "show configuration" for configuration details.
>>> For bug reporting instructions, please see:
>>> <http://www.gnu.org/software/gdb/bugs/>.
>>> Find the GDB manual and other documentation resources online at:
>>> <http://www.gnu.org/software/gdb/documentation/>.
>>>
>>> For help, type "help".
>>> Type "apropos word" to search for commands related to "word"...
>>> Reading symbols from rockefeller.exe...done.
>>> (gdb) b request_time_to_run()
>>> Breakpoint 1 at 0x1004010e8: file rockefeller.cpp, line 10.
>>> (gdb) r
>>> Starting program: /wip/rockefeller.exe
>>>
>>> Thread 1 "rockefeller" hit Breakpoint 1, request_time_to_run () at 
>>> rockefeller.cpp:10
>>> 10float tm = 0.0;// Time duration (sec)
>>> (gdb) n
>>> 11std::string ans = "";  // interactive answer for time duration
>>> (gdb) n
>>> 12std::cout << "Supply the equivalent of runtime in seconds. \n";
>>> (gdb) n
>>> Supply the equivalent of runtime in seconds.
>>> 13std::cout << "Note: time=0 will stop main. \n";
>>> (gdb) n
>>> Note: time=0 will stop main.
>>> 14std::cin >> ans;
>>> (gdb) n
>>> 1
>>> 15if ( (int)(ans[0]) < 48 || (int)(ans[0] > 57) ) {
>>> (gdb) n
>>> 19  int j = 0;
>>> (gdb) c
>>> Continuing.
>>> a is 1.00
>>> [Inferior 1 (process 12660) exited normally]


>>> But, simple stuff does run correctly in gdb stopping for terminal input at
>>>std::cin

RE: cin and read(*,*) not waiting for kbd input in gdb

[Rockefeller, Harry]

>>-Original Message-
>>From: Jon Turney 
>Sent: Friday, January 17, 2020 9:40 AM
>To: The Cygwin Mailing List 
>Cc: Rockefeller, Harry 
>Subject: Re: cin and read(*,*) not waiting for kbd input in gdb
>EXTERNAL EMAIL: STOP and verify sender address, links, and attachments before 
>taking action.
>On 16/01/2020 21:02, Rockefeller, Harry wrote:
>> Both the Fortran and cpp used to work correctly when run in gdb.
>
>Thanks for reporting this problem.
>
>I assume this means that this worked with gdb-8.1.1-1, but not with
>gdb-8.2.1-1 (Made available for testing 2019-03-21 [1], promoted to current 
>2020-01-07 [2])
>
>Firstly, can I suggest that if a working gdb is important to you, you try test 
>versions when they are available.  Wider testing helps me make good releases 
>of gdb.
>Secondly, can you try the recently made test release of gdb-8.3.1-1 [3], to 
>see if this behaves differently?  If that doesn't help, you can downgrade to 
>8.1.1-1 for the moment...

I certainly plan to do that as soon as problem(s) are identified.

>[1] https://cygwin.com/ml/cygwin-announce/2019-03/msg00032.html
>[2] https://cygwin.com/ml/cygwin/2020-01/msg00064.html
>[3] https://cygwin.com/ml/cygwin-announce/2019-12/msg00033.html
>
>> FWIW, Both Fortran and cpp work correctly, stopping for keyboard input, when 
>> run outside of gdb.
>>
>> But now, code simply doesn't stop to take keyboard input inside gdb.
>>
>> [C++ test code omitted for brevity]

>I'm not able to reproduce this problem.  Perhaps you can provide a similar 
>transcript showing the steps to reproduce?

I see that when I ran it I also had a few lines like these:
[New Thread 6188.0x1e54].
Since I develop mostly for "hard" real time, my default boot is a Win7 with RTX.
I rebooted my pc with the Win7 alone (no RTX) and the stdin does work as you 
show below.
I am working with my software support staff to find out if anything changed 
recently in my PC boot stuff.

>> $ gdb rockefeller.exe
>> GNU gdb (GDB) (Cygwin 8.2.1-1) 8.2.1
>> Copyright (C) 2018 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 "x86_64-pc-cygwin".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> <http://www.gnu.org/software/gdb/bugs/>.
>> Find the GDB manual and other documentation resources online at:
>> <http://www.gnu.org/software/gdb/documentation/>.
>>
>> For help, type "help".
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from rockefeller.exe...done.
>> (gdb) b request_time_to_run()
>> Breakpoint 1 at 0x1004010e8: file rockefeller.cpp, line 10.
>> (gdb) r
>> Starting program: /wip/rockefeller.exe
>>
>> Thread 1 "rockefeller" hit Breakpoint 1, request_time_to_run () at 
>> rockefeller.cpp:10
>> 10float tm = 0.0;// Time duration (sec)
>> (gdb) n
>> 11std::string ans = "";  // interactive answer for time duration
>> (gdb) n
>> 12std::cout << "Supply the equivalent of runtime in seconds. \n";
>> (gdb) n
>> Supply the equivalent of runtime in seconds.
>> 13std::cout << "Note: time=0 will stop main. \n";
>> (gdb) n
>> Note: time=0 will stop main.
>> 14std::cin >> ans;
>> (gdb) n
>> 1
>> 15if ( (int)(ans[0]) < 48 || (int)(ans[0] > 57) ) {
>> (gdb) n
>> 19  int j = 0;
>> (gdb) c
>> Continuing.
>> a is 1.00
>> [Inferior 1 (process 12660) exited normally]


>> But, simple stuff does run correctly in gdb stopping for terminal input at
>>std::cin >> ans;
>> FWIW, for simple cpp above neither the cout nor the cin works directly (not 
>> running in gdb).

>Although not related to gdb, that would be a serious cygwin bug.

I am still in the Win7 only boot on my PC ...  no RTX

More on this last problem.  This time using Fortran.
Test code:
  program test
  implicit none
  realcycle_time_preset /0.0/ ! (seconds)
  realcycle_length /0.0/  ! (seconds)
  do
 if (cycle_time_preset.le.0.0) then
write(*,*)'Supply the equivalent of run time in seconds.'
write(*,"('(Note: a negative run time will stop run): ',$)")
read(*,*) cycle_length
 else
cycle_length = cycle_time_preset
 end if
 if (cycle_length .lt. 0.0) stop 'normal termination'
  end do
  stop
  end

$ /usr/bin/gfortran   -g -ffree-form -ffree-line-length-none -Wunused 
-ffpe-trap=invalid,zero,overflow -o test.exe test.f

harryr@HARRYR-PC ~/
$ test.exe

$
Neither standard output nor input works.
FWIW, running in gdb both standard input and output work.

Re: cin and read(*,*) not waiting for kbd input in gdb

[Jon Turney]

On 16/01/2020 21:02, Rockefeller, Harry wrote:

Both the Fortran and cpp used to work correctly when run in gdb.


Thanks for reporting this problem.

I assume this means that this worked with gdb-8.1.1-1, but not with 
gdb-8.2.1-1 (Made available for testing 2019-03-21 [1], promoted to 
current 2020-01-07 [2])


Firstly, can I suggest that if a working gdb is important to you, you 
try test versions when they are available.  Wider testing helps me make 
good releases of gdb.


Secondly, can you try the recently made test release of gdb-8.3.1-1 [3], 
to see if this behaves differently?  If that doesn't help, you can 
downgrade to 8.1.1-1 for the moment...


[1] https://cygwin.com/ml/cygwin-announce/2019-03/msg00032.html
[2] https://cygwin.com/ml/cygwin/2020-01/msg00064.html
[3] https://cygwin.com/ml/cygwin-announce/2019-12/msg00033.html


FWIW, Both Fortran and cpp work correctly, stopping for keyboard input, when 
run outside of gdb.

But now, code simply doesn't stop to take keyboard input inside gdb.

I've tried simplifying cpp problem with simple code.
e.g.
#include  // to enable terminal printout
#include // pow function
int main() {
   float request_time_to_run(void);
   float a=0.0f;
   a = request_time_to_run();
   printf ("a is %f\n", a);
}
float request_time_to_run() {
   float tm = 0.0;// Time duration (sec)
   std::string ans = "";  // interactive answer for time duration
   std::cout << "Supply the equivalent of runtime in seconds. \n";
   std::cout << "Note: time=0 will stop main. \n";
   std::cin >> ans;
   if ( (int)(ans[0]) < 48 || (int)(ans[0] > 57) ) {
 tm = 1.0;
   } else {
 int i;
 int j = 0;
 tm = 0.0;
 for (i=ans.length() - 1; i>=0; i--) {
   tm += ((int)(ans[i]) - 48) * pow( 10, j++);
 }
   }
   return tm;
}



I'm not able to reproduce this problem.  Perhaps you can provide a 
similar transcript showing the steps to reproduce?



$ gdb rockefeller.exe
GNU gdb (GDB) (Cygwin 8.2.1-1) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
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 "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from rockefeller.exe...done.
(gdb) b request_time_to_run()
Breakpoint 1 at 0x1004010e8: file rockefeller.cpp, line 10.
(gdb) r
Starting program: /wip/rockefeller.exe

Thread 1 "rockefeller" hit Breakpoint 1, request_time_to_run () at 
rockefeller.cpp:10
10float tm = 0.0;// Time duration (sec)
(gdb) n
11std::string ans = "";  // interactive answer for time duration
(gdb) n
12std::cout << "Supply the equivalent of runtime in seconds. \n";
(gdb) n
Supply the equivalent of runtime in seconds.
13std::cout << "Note: time=0 will stop main. \n";
(gdb) n
Note: time=0 will stop main.
14std::cin >> ans;
(gdb) n
1
15if ( (int)(ans[0]) < 48 || (int)(ans[0] > 57) ) {
(gdb) n
19  int j = 0;
(gdb) c
Continuing.
a is 1.00
[Inferior 1 (process 12660) exited normally]




But, simple stuff does run correctly in gdb stopping for terminal input at
   std::cin >> ans;
FWIW, for simple cpp above neither the cout nor the cin works directly (not 
running in gdb).


Although not related to gdb, that would be a serious cygwin bug.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple