This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Hello Craighton,

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 
it...)

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 
console...

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 
unused port.

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 
off...)

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.

wkr,
	Thomas.

> 
> 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.
> >
> 

--------------------------------------------
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler           Herbststrasse 8
D-82178 Puchheim          Germany
email:    Thomas.Doerfler@imd-systems.de
PGP public key available at: http://www.imd-
systems.de/pgp_keys.htm


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]