This is the mail archive of the
mailing list for the GDB project.
Re: Problem with COM1 port from with GDB 5.3 under Cygwin 1.5.3-1
- From: "Thomas Doerfler" <Thomas dot Doerfler at imd-systems dot de>
- To: Creighton MacDonnell <creighton at macdonnell dot ca>
- Cc: Thomas Doerfler <Thomas dot Doerfler at imd-systems dot de>, gdb at sources dot redhat dot com
- Date: Wed, 10 Sep 2003 20:53:23 +0200
- Subject: Re: Problem with COM1 port from with GDB 5.3 under Cygwin 1.5.3-1
- Organization: IMD
- References: <3F5F5C7D.5659.2D0964@localhost>
I have tested around a bit, I executed my cross-gdb under a
native gdb to step through the serial code. For convenience, I
executed the cross-gdb without its nice and colored "insight"
GUI (using the "-nw" switch on the cross-gdb command line).
After half an hour of debugging, I got the message back, that
the serial connection to my target is up and running... (We
call this a Heisenbug, you can't find it, when you look at
When I start my cross-gdb directly from command line and also
disable the Insight GUI (-nw once again), I also get the
serial connection up (!!!). Another funny detail: When I
terminate my gdb session, I don't get any more echos on my
So, here are the facts that spin in my mind:
1. With Insight GUI enabled: When I try to use a serial port
in GDB, that is used by another application, I get a slightly
different error message than in the case when I try to open an
2. Without Insight GUI: I can properly open a (unused) serial
port and communicate with my target. But afterwards, the
settings of stdin/stdout of gdb are set to wrong options (echo
So my current theory: gdb can open serial devices under
cygwin, but maybe when it tries to apply the line settings
(echo, special characters etc) it sets these features TO THE
WRONG DESCRIPTOR, to stdin/out instead of the serial device.
This works more or less as long as stdin/out is a tty type
device, but it fails, if it is redirected to the "insight"
console window. In the later case, the ominous "is not a
typewriter" message get thrown, or a "Permission denied"...
I will try to verify that.
> 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
> Thomas Doerfler wrote:
> >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
> >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...
> > Thomas.
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler Herbststrasse 8
D-82178 Puchheim Germany
PGP public key available at: http://www.imd-