Problem with COM1 port from with GDB 5.3 under Cygwin 1.5.3-1

[Creighton MacDonnell]

As I mentioned in my first posting,  the code in GDB for accessing 
serial ports seems quite complicated. It does not just attempt to open 
whatever you specifiy for a device name. There is code that builds up 
some sort of "list of devices".

I expect this is to assist portability. But iin this case I think it is 
doing the opposite. When I tried to use "/dev/ttyS0" as a device name 
under the old Cygwin, GDB would say it "could not open the device". But 
I think what may actually be happening is that "/dev/ttyS0" did not make 
it into the list of devices.

I fear that GDB may be attempting to get a list of interfaces, or 
information about interfaces, using some sort of lower level system 
calls which Cygwin just stubs out. This might not only cause GDB to not 
realize the device name is actually OK, but may cause it to attempt to 
open COM? with inapproriate options.

If I were a Cygwin maintainer, and knew that GDB did not allow names 
such as "/dev/ttyS0" under the old Cygwin, I might react that GDB should 
be made "Cygwin-compatible" first. And after that, if there are still 
problems with the "com?" names, they may want debug information that 
could only be obtained by putting debug code into GDB.

In the end, it is we GDB under Cygwin users that have the problem. It 
does not appear that many other Cygwin users care much about the serial 
port.

Thomas Doerfler wrote:

>Hello,
>
>I just have passed some similar tests. I have connected a 
>Win32 terminal program to one COM port, and was trying to send 
>data to the other port using cygwin, with a loopback (null-
>modem) cable attached.
>
>I could 
>
>$ echo bla >/dev/ttyS1
>
>and even
>
>$ echo bla >COM2
>
>
>and got the result on the serial line (and into my terminal 
>screen)
>
>So at least sendig data from cygwin works fine.
>
>Currently I don't know how to come around this. The problem 
>seems to be more connected to cygwin, because we see this with 
>at least two different gdb versions...
>
>wkr,
>	Thomas.
>