public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* Re: Problem with COM1 port from with GDB 5.3 under Cygwin 1.5.3-1
@ 2003-09-10 11:54 Thomas Doerfler
  2003-09-10 14:55 ` Creighton MacDonnell
  0 siblings, 1 reply; 12+ messages in thread
From: Thomas Doerfler @ 2003-09-10 11:54 UTC (permalink / raw)
  To: gdb; +Cc: Creighton MacDonnell

Hello,

I have read your posting to the gdb mailing list. Some days 
now I have a similar problem with a M68K-GDB5.2 working with 
the serial remote protocol under cygwin 1.5.3.

My gdb complains, that COM1 is "not a typewriter", and it will 
open the alternative deivces "/dev/ttyS0" only in vary rare 
occasions.

I will try to downgrade my cygwin installation and try 
again...
wkr,
	Thomas.

^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: Problem with COM1 port from with GDB 5.3 under Cygwin 1.5.3-1
@ 2003-09-23 19:07 Creighton MacDonnell
  2003-09-24  5:24 ` Eli Zaretskii
  0 siblings, 1 reply; 12+ messages in thread
From: Creighton MacDonnell @ 2003-09-23 19:07 UTC (permalink / raw)
  To: gdb-patches; +Cc: gdb

I earlier posted to the gdb@sources.redhat.com list about a problem 
using the serial port on Cygwin 1.5.3 when using RDI (i.e. ARM Angel 
Debug Protocol) with GDB 5.3.

Using "com1" would hang, and GDB had never allowed names like 
"/dev/ttyS0", which Cygwin was supposed to support.

This patch avoids the Cygwin 1.5.* problem with "com*" port names, while 
still allowing "com*" names to be used in GDB scripts (they get 
translated to "/dev/com?"), and also allows "/dev/ttyS*" and "/dev/com*" 
device names to be used.


--- ./gdb/rdi-share/unixcomm.c~    2002-06-08 14:34:41.000000000 -0600
+++ ./gdb/rdi-share/unixcomm.c    2003-09-23 12:12:43.703125000 -0600
@@ -96,7 +96,15 @@
 #define PARPORT2   "/dev/par1"
 #endif
 
-#if defined(_WIN32) || defined (__CYGWIN__)
+#if defined (__CYGWIN__)
+#define SERIAL_PREFIX "/dev/com"
+#define SERPORT1   "/dev/com1"
+#define SERPORT2   "/dev/com2"
+#define PARPORT1   "lpt1"
+#define PARPORT2   "lpt2"
+#endif
+
+#if defined(_WIN32)
 #define SERIAL_PREFIX "com"
 #define SERPORT1   "com1"
 #define SERPORT2   "com2"
@@ -154,6 +162,32 @@
   }
   if (strcmp(name, "2") == 0) return SERPORT2;
 
+  #if defined (__CYGWIN__)
+
+  /* allow Linux "/dev/ttyS*" names too */
+  if (strncmp(name, "/dev/ttyS", 9) == 0) return name;
+
+  /* allow Windows "com*" names too */
+  {
+    static const char *const real_name[] = {
+        SERIAL_PREFIX "0",
+        SERIAL_PREFIX "1",
+        SERIAL_PREFIX "2",
+        SERIAL_PREFIX "3",
+        SERIAL_PREFIX "4",
+        SERIAL_PREFIX "5",
+        SERIAL_PREFIX "6",
+        SERIAL_PREFIX "7",
+        SERIAL_PREFIX "8",
+        SERIAL_PREFIX "9",
+        };
+    if (strlen(name) == 4 && strncmp(name, "com", 3) == 0 &&
+        '0' <= name[3] && name[3] <= '9')
+      return real_name[name[3] - '0'];
+  }
+
+  #endif
+
   /* It wasn't one of the simple cases, so now we have to parse it
    * properly
    */

^ permalink raw reply	[flat|nested] 12+ messages in thread
* Problem with COM1 port from with GDB 5.3 under Cygwin 1.5.3-1
@ 2003-09-08 21:41 Creighton MacDonnell
  0 siblings, 0 replies; 12+ messages in thread
From: Creighton MacDonnell @ 2003-09-08 21:41 UTC (permalink / raw)
  To: gdb


I upgraded my Cygwin installation a few days ago (Thursday, September 4) 
to the new 1.5.3-1 version, from the previous 1.3.22-1 version.

This broke a self-compiled (under the previous 1.3.22-1 version of 
Cygwin) version of GDB 5.3 compiled for "arm-elf" that I use.

It seems to me that GDB simply hangs after opening the COM1 serial port 
when trying to make an "RDI" (Angel Debug) connection.

I have recompiled my GNU tools with the new version of Cygwin but I have 
the same problem.

I still have my old installation of Cygwin, which still works. From this 
I know that the problem is not  with the target board or the serial port 
on my PC.

So something has changed in the Cygwin support for serial devices.

I have posted to the Cygwin mailing list, but I thought I would try this 
list too.

I had noticed previously that GDB would not use a serial port if it was 
refered to as /dev/com1 or /dev/ttyS0 (it would say and still says that 
it could not open it), although Cygwin claims to support these names. 
But it did work if "com1" was used as the device name.

I have looked at the code for serial device access in the GDB source, 
and it does not seem to make any special allowance for Cygwin. I see in 
the GDB code (after only a very quick look) some sort of  "serial 
interface discovery" process. This suggests that GDB does not just go 
ahead and attempt to open the device name. So understanding this code 
would probably not be trivial.

Does anyone else on this list use GDB in this way? Do you also have 
problems with Cygwin 1.5.1-1?

Is there anyone on this list with insight into the GDB code for 
accessing serial ports who might be able to suggest a hack that I might 
attempt to the code?

Thanks.


^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2003-09-24 18:12 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-09-10 11:54 Problem with COM1 port from with GDB 5.3 under Cygwin 1.5.3-1 Thomas Doerfler
2003-09-10 14:55 ` Creighton MacDonnell
2003-09-10 15:18   ` Thomas Doerfler
2003-09-10 16:48     ` Creighton MacDonnell
2003-09-10 18:55       ` Thomas Doerfler
2003-09-10 18:56       ` Problem with COM1 port from with GDB 5.3 under cygwin 1.5.3-1 Christopher Faylor
2003-09-10 20:05         ` Creighton MacDonnell
2003-09-10 21:58           ` Christopher Faylor
  -- strict thread matches above, loose matches on Subject: below --
2003-09-23 19:07 Problem with COM1 port from with GDB 5.3 under Cygwin 1.5.3-1 Creighton MacDonnell
2003-09-24  5:24 ` Eli Zaretskii
2003-09-24 18:12   ` Problem with COM1 port from with GDB 5.3 under cygwin 1.5.3-1 Christopher Faylor
2003-09-08 21:41 Problem with COM1 port from with GDB 5.3 under Cygwin 1.5.3-1 Creighton MacDonnell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).