[RFA] Remote UDP support

[RFA] Remote UDP support

[Daniel Jacobowitz]

A patch for this feature was supported a year or so ago, but never went in. 
I had a need for this a couple of days ago, so I did it over from scratch;
it's much easier now than it was at the time.  The name of ser-tcp.c is a
bit wrong after this patch; I can either rename the file to ser-net.c or
just update some comments to match.  Got a preference?  Otherwise OK?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

2002-05-08  Daniel Jacobowitz  <drow@mvista.com>

	* ser-tcp.c: Include <netinet/udp.h>.  Rename tcp_open
	and tcp_close to net_open and net_close.
	(net_open): Accept "udp:" and "tcp:" specifications.  Connect
	using UDP if requested.  Don't try to disable Nagle on UDP
	sockets.

Index: ser-tcp.c
===================================================================
RCS file: /cvs/src/src/gdb/ser-tcp.c,v
retrieving revision 1.10
diff -u -p -r1.10 ser-tcp.c
--- ser-tcp.c	18 Dec 2001 18:54:18 -0000	1.10
+++ ser-tcp.c	8 May 2002 23:21:58 -0000
@@ -38,12 +38,13 @@
 #include <netdb.h>
 #include <sys/socket.h>
 #include <netinet/tcp.h>
+#include <netinet/udp.h>
 
 #include <signal.h>
 #include "gdb_string.h"
 
-static int tcp_open (struct serial *scb, const char *name);
-static void tcp_close (struct serial *scb);
+static int net_open (struct serial *scb, const char *name);
+static void net_close (struct serial *scb);
 extern int (*ui_loop_hook) (int);
 void _initialize_ser_tcp (void);
 
@@ -55,17 +56,27 @@ void _initialize_ser_tcp (void);
 /* Open a tcp socket */
 
 static int
-tcp_open (struct serial *scb, const char *name)
+net_open (struct serial *scb, const char *name)
 {
   char *port_str, hostname[100];
   int n, port, tmp;
+  int use_udp;
   struct hostent *hostent;
   struct sockaddr_in sockaddr;
 
+  use_udp = 0;
+  if (strncmp (name, "udp:", 4) == 0)
+    {
+      use_udp = 1;
+      name = name + 4;
+    }
+  else if (strncmp (name, "tcp:", 4) == 0)
+    name = name + 4;
+
   port_str = strchr (name, ':');
 
   if (!port_str)
-    error ("tcp_open: No colon in host name!");	   /* Shouldn't ever happen */
+    error ("net_open: No colon in host name!");	   /* Shouldn't ever happen */
 
   tmp = min (port_str - name, (int) sizeof hostname - 1);
   strncpy (hostname, name, tmp);	/* Don't want colon */
@@ -84,7 +95,11 @@ tcp_open (struct serial *scb, const char
       return -1;
     }
 
-  scb->fd = socket (PF_INET, SOCK_STREAM, 0);
+  if (use_udp)
+    scb->fd = socket (PF_INET, SOCK_DGRAM, 0);
+  else
+    scb->fd = socket (PF_INET, SOCK_STREAM, 0);
+
   if (scb->fd < 0)
     return -1;
   
@@ -102,7 +117,7 @@ tcp_open (struct serial *scb, const char
 
   if (n < 0 && errno != EINPROGRESS)
     {
-      tcp_close (scb);
+      net_close (scb);
       return -1;
     }
 
@@ -124,7 +139,7 @@ tcp_open (struct serial *scb, const char
 	      if (ui_loop_hook (0))
 		{
 		  errno = EINTR;
-		  tcp_close (scb);
+		  net_close (scb);
 		  return -1;
 		}
 	    }
@@ -142,7 +157,7 @@ tcp_open (struct serial *scb, const char
 	{
 	  if (polls > TIMEOUT * POLL_INTERVAL)
 	    errno = ETIMEDOUT;
-	  tcp_close (scb);
+	  net_close (scb);
 	  return -1;
 	}
     }
@@ -156,20 +171,23 @@ tcp_open (struct serial *scb, const char
       {
 	if (err)
 	  errno = err;
-	tcp_close (scb);
+	net_close (scb);
 	return -1;
       }
   } 
-  
+
   /* turn off nonblocking */
   tmp = 0;
   ioctl (scb->fd, FIONBIO, &tmp);
 
-  /* Disable Nagle algorithm. Needed in some cases. */
-  tmp = 1;
-  setsockopt (scb->fd, IPPROTO_TCP, TCP_NODELAY,
-	      (char *)&tmp, sizeof (tmp));
-  
+  if (use_udp == 0)
+    {
+      /* Disable Nagle algorithm. Needed in some cases. */
+      tmp = 1;
+      setsockopt (scb->fd, IPPROTO_TCP, TCP_NODELAY,
+		  (char *)&tmp, sizeof (tmp));
+    }
+
   /* If we don't do this, then GDB simply exits
      when the remote side dies.  */
   signal (SIGPIPE, SIG_IGN);
@@ -178,7 +196,7 @@ tcp_open (struct serial *scb, const char
 }
 
 static void
-tcp_close (struct serial *scb)
+net_close (struct serial *scb)
 {
   if (scb->fd < 0)
     return;
@@ -194,8 +212,8 @@ _initialize_ser_tcp (void)
   memset (ops, sizeof (struct serial_ops), 0);
   ops->name = "tcp";
   ops->next = 0;
-  ops->open = tcp_open;
-  ops->close = tcp_close;
+  ops->open = net_open;
+  ops->close = net_close;
   ops->readchar = ser_unix_readchar;
   ops->write = ser_unix_write;
   ops->flush_output = ser_unix_nop_flush_output;

Re: [RFA] Remote UDP support

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> A patch for this feature was supported a year or so ago, but never went in.
> I had a need for this a couple of days ago, so I did it over from scratch;
> it's much easier now than it was at the time.  The name of ser-tcp.c is a
> bit wrong after this patch; I can either rename the file to ser-net.c or
> just update some comments to match.  Got a preference?  Otherwise OK?
> 
> --
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer

Wow!  I love the simplicity of the change.  Nice job.
I'm not sure if I understand all the ramifications, though.
If you call net_open, how is it going to decide whether 
to use udp or tcp?  I imagine we would want it to use
tcp by preference, if possible.


> 
> 2002-05-08  Daniel Jacobowitz  <drow@mvista.com>
> 
>         * ser-tcp.c: Include <netinet/udp.h>.  Rename tcp_open
>         and tcp_close to net_open and net_close.
>         (net_open): Accept "udp:" and "tcp:" specifications.  Connect
>         using UDP if requested.  Don't try to disable Nagle on UDP
>         sockets.
> 
> Index: ser-tcp.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/ser-tcp.c,v
> retrieving revision 1.10
> diff -u -p -r1.10 ser-tcp.c
> --- ser-tcp.c   18 Dec 2001 18:54:18 -0000      1.10
> +++ ser-tcp.c   8 May 2002 23:21:58 -0000
> @@ -38,12 +38,13 @@
>  #include <netdb.h>
>  #include <sys/socket.h>
>  #include <netinet/tcp.h>
> +#include <netinet/udp.h>
> 
>  #include <signal.h>
>  #include "gdb_string.h"
> 
> -static int tcp_open (struct serial *scb, const char *name);
> -static void tcp_close (struct serial *scb);
> +static int net_open (struct serial *scb, const char *name);
> +static void net_close (struct serial *scb);
>  extern int (*ui_loop_hook) (int);
>  void _initialize_ser_tcp (void);
> 
> @@ -55,17 +56,27 @@ void _initialize_ser_tcp (void);
>  /* Open a tcp socket */
> 
>  static int
> -tcp_open (struct serial *scb, const char *name)
> +net_open (struct serial *scb, const char *name)
>  {
>    char *port_str, hostname[100];
>    int n, port, tmp;
> +  int use_udp;
>    struct hostent *hostent;
>    struct sockaddr_in sockaddr;
> 
> +  use_udp = 0;
> +  if (strncmp (name, "udp:", 4) == 0)
> +    {
> +      use_udp = 1;
> +      name = name + 4;
> +    }
> +  else if (strncmp (name, "tcp:", 4) == 0)
> +    name = name + 4;
> +
>    port_str = strchr (name, ':');
> 
>    if (!port_str)
> -    error ("tcp_open: No colon in host name!");           /* Shouldn't ever happen */
> +    error ("net_open: No colon in host name!");           /* Shouldn't ever happen */
> 
>    tmp = min (port_str - name, (int) sizeof hostname - 1);
>    strncpy (hostname, name, tmp);       /* Don't want colon */
> @@ -84,7 +95,11 @@ tcp_open (struct serial *scb, const char
>        return -1;
>      }
> 
> -  scb->fd = socket (PF_INET, SOCK_STREAM, 0);
> +  if (use_udp)
> +    scb->fd = socket (PF_INET, SOCK_DGRAM, 0);
> +  else
> +    scb->fd = socket (PF_INET, SOCK_STREAM, 0);
> +
>    if (scb->fd < 0)
>      return -1;
> 
> @@ -102,7 +117,7 @@ tcp_open (struct serial *scb, const char
> 
>    if (n < 0 && errno != EINPROGRESS)
>      {
> -      tcp_close (scb);
> +      net_close (scb);
>        return -1;
>      }
> 
> @@ -124,7 +139,7 @@ tcp_open (struct serial *scb, const char
>               if (ui_loop_hook (0))
>                 {
>                   errno = EINTR;
> -                 tcp_close (scb);
> +                 net_close (scb);
>                   return -1;
>                 }
>             }
> @@ -142,7 +157,7 @@ tcp_open (struct serial *scb, const char
>         {
>           if (polls > TIMEOUT * POLL_INTERVAL)
>             errno = ETIMEDOUT;
> -         tcp_close (scb);
> +         net_close (scb);
>           return -1;
>         }
>      }
> @@ -156,20 +171,23 @@ tcp_open (struct serial *scb, const char
>        {
>         if (err)
>           errno = err;
> -       tcp_close (scb);
> +       net_close (scb);
>         return -1;
>        }
>    }
> -
> +
>    /* turn off nonblocking */
>    tmp = 0;
>    ioctl (scb->fd, FIONBIO, &tmp);
> 
> -  /* Disable Nagle algorithm. Needed in some cases. */
> -  tmp = 1;
> -  setsockopt (scb->fd, IPPROTO_TCP, TCP_NODELAY,
> -             (char *)&tmp, sizeof (tmp));
> -
> +  if (use_udp == 0)
> +    {
> +      /* Disable Nagle algorithm. Needed in some cases. */
> +      tmp = 1;
> +      setsockopt (scb->fd, IPPROTO_TCP, TCP_NODELAY,
> +                 (char *)&tmp, sizeof (tmp));
> +    }
> +
>    /* If we don't do this, then GDB simply exits
>       when the remote side dies.  */
>    signal (SIGPIPE, SIG_IGN);
> @@ -178,7 +196,7 @@ tcp_open (struct serial *scb, const char
>  }
> 
>  static void
> -tcp_close (struct serial *scb)
> +net_close (struct serial *scb)
>  {
>    if (scb->fd < 0)
>      return;
> @@ -194,8 +212,8 @@ _initialize_ser_tcp (void)
>    memset (ops, sizeof (struct serial_ops), 0);
>    ops->name = "tcp";
>    ops->next = 0;
> -  ops->open = tcp_open;
> -  ops->close = tcp_close;
> +  ops->open = net_open;
> +  ops->close = net_close;
>    ops->readchar = ser_unix_readchar;
>    ops->write = ser_unix_write;
>    ops->flush_output = ser_unix_nop_flush_output;

Re: [RFA] Remote UDP support

[Daniel Jacobowitz]

On Wed, May 08, 2002 at 04:44:50PM -0700, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> > 
> > A patch for this feature was supported a year or so ago, but never went in.
> > I had a need for this a couple of days ago, so I did it over from scratch;
> > it's much easier now than it was at the time.  The name of ser-tcp.c is a
> > bit wrong after this patch; I can either rename the file to ser-net.c or
> > just update some comments to match.  Got a preference?  Otherwise OK?
> > 
> > --
> > Daniel Jacobowitz                           Carnegie Mellon University
> > MontaVista Software                         Debian GNU/Linux Developer
> 
> Wow!  I love the simplicity of the change.  Nice job.

I actually leave non-blocking connects enabled for UDP, because it kept
the changes smaller.  It's kind of silly, if you think about it, though :)

> I'm not sure if I understand all the ramifications, though.
> If you call net_open, how is it going to decide whether 
> to use udp or tcp?  I imagine we would want it to use
> tcp by preference, if possible.

Ack, I forgot to include the accompanying documentation changes.  Bad
Dan!  The gist is that you can say "host:port" or ":port" and get TCP,
"udp:host:port" or "udp::port" and get UDP, or "tcp:host:port" or
"tcp::port" and get TCP.  So you can connect by TCP to a host named
UDP, etc.

Here's the matching documentation patch.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

2002-05-08  Daniel Jacobowitz  <drow@mvista.com>

	* gdb.texinfo (Debug Session): Document new `udp:' and `tcp:'
	options for `target remote'.

Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.98
diff -u -r1.98 gdb.texinfo
--- gdb.texinfo	4 May 2002 16:00:30 -0000	1.98
+++ gdb.texinfo	9 May 2002 00:10:17 -0000
@@ -10485,7 +10485,8 @@
 
 @cindex TCP port, @code{target remote}
 To use a TCP connection, use an argument of the form
-@code{@var{host}:port}.  For example, to connect to port 2828 on a
+@code{@var{host}:@var{port}} or @code{tcp:@var{host}:@var{port}}.
+For example, to connect to port 2828 on a
 terminal server named @code{manyfarms}:
 
 @smallexample
@@ -10503,6 +10504,15 @@
 @noindent
 
 Note that the colon is still required here.
+
+@cindex UDP port, @code{target remote}
+To use a UDP connection, use an argument of the form
+@code{udp:@var{host}:@var{port}}.  For example, to connect to UDP port 2828
+on a terminal server named @code{manyfarms}:
+
+@smallexample
+target remote udp:manyfarms:2828
+@end smallexample
 @end enumerate
 
 Now you can use all the usual commands to examine and change data and to

Re: [RFA] Remote UDP support

[Andrew Cagney]

> A patch for this feature was supported a year or so ago, but never went in. 

(lack of assignment the last time it was posted from memory).

> I had a need for this a couple of days ago, so I did it over from scratch;
> it's much easier now than it was at the time.  The name of ser-tcp.c is a
> bit wrong after this patch; I can either rename the file to ser-net.c or
> just update some comments to match.  Got a preference?  Otherwise OK?

 From memory, the last time this came up the conclusion was that:

- It isn't at all reliable (rather than mostly reliable as across TCP or 
serial).  The entire ``T'' stop packet can be lost and neither GDB, nor 
the target, would notice.

- it wasn't necessary - there are micro tcp implementations around that 
implement sufficient TCP for the remote protocol to work

Check the archives (search for mark salter?).

One theory put forward was to have GDB print a banner(6) sized warning 
(and get confirmation) before accepting the option.

Andrew

Re: [RFA] Remote UDP support

[Daniel Jacobowitz]

On Wed, May 08, 2002 at 08:39:25PM -0400, Andrew Cagney wrote:
> >A patch for this feature was supported a year or so ago, but never went 
> >in. 
> 
> (lack of assignment the last time it was posted from memory).

Yep.

> >I had a need for this a couple of days ago, so I did it over from scratch;
> >it's much easier now than it was at the time.  The name of ser-tcp.c is a
> >bit wrong after this patch; I can either rename the file to ser-net.c or
> >just update some comments to match.  Got a preference?  Otherwise OK?
> 
> From memory, the last time this came up the conclusion was that:

I didn't see any of these conclusions when I looked.  Oh well.  None of
them were in the thread with the original patch or the discussion about
queuing it for 5.1.

> - It isn't at all reliable (rather than mostly reliable as across TCP or 
> serial).  The entire ``T'' stop packet can be lost and neither GDB, nor 
> the target, would notice.

Certainly.  I also see a comment about the G packet needing to fit in
one UDP packet, although I'm not 100% sure that's right.

> - it wasn't necessary - there are micro tcp implementations around that 
> implement sufficient TCP for the remote protocol to work

Still bigger than a polled UDP implementation, and much more
complicated.  Implementing a tiny UDP stack is simple!  Sure, it isn't
reliable at all; so use it on small networks and be careful :)

> Check the archives (search for mark salter?).

You vastly overestimate ht:/Dig if you think that's possible.  I really
want that program killed.

> One theory put forward was to have GDB print a banner(6) sized warning 
> (and get confirmation) before accepting the option.

I have to admit, I don't see the point.  A big warning in the
documentation, maybe, but such a confirmation query would drive me
crazy if I actually needed to use this regularly.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] Remote UDP support

[Andrew Cagney]

> I didn't see any of these conclusions when I looked.  Oh well.  None of
> them were in the thread with the original patch or the discussion about
> queuing it for 5.1.

Must be earlier.  I'm also digging.

>> - It isn't at all reliable (rather than mostly reliable as across TCP or 
>> serial).  The entire ``T'' stop packet can be lost and neither GDB, nor 
>> the target, would notice.
> 
> 
> Certainly.  I also see a comment about the G packet needing to fit in
> one UDP packet, although I'm not 100% sure that's right.

I suspect the comment relates to a ``be nice'' to some TCP stacks, and 
possibly to the now removed packet sequence number code (never worked).

>> - it wasn't necessary - there are micro tcp implementations around that 
>> implement sufficient TCP for the remote protocol to work
> 
> 
> Still bigger than a polled UDP implementation, and much more
> complicated.  Implementing a tiny UDP stack is simple!  Sure, it isn't
> reliable at all; so use it on small networks and be careful :)

>> One theory put forward was to have GDB print a banner(6) sized warning 
>> (and get confirmation) before accepting the option.
> 
> 
> I have to admit, I don't see the point.  A big warning in the
> documentation, maybe, but such a confirmation query would drive me
> crazy if I actually needed to use this regularly.

That is the point!  I don't want to be around when someone that (shock 
horror :-) fails to read the manual and then complains that the GDB 
remote protocol isn't reliable.  What about a:

set remote 
i-do-not-understand-gdb-remote-protocol-and-foolishly-think-udp-works-so-please-enable-it 
  on

option.

Have you tried running the testsuite across UDP?

enjoy,
Andrew

Re: [RFA] Remote UDP support

[Daniel Jacobowitz]

On Wed, May 08, 2002 at 10:56:35PM -0400, Andrew Cagney wrote:
> >>- it wasn't necessary - there are micro tcp implementations around that 
> >>implement sufficient TCP for the remote protocol to work
> >
> >
> >Still bigger than a polled UDP implementation, and much more
> >complicated.  Implementing a tiny UDP stack is simple!  Sure, it isn't
> >reliable at all; so use it on small networks and be careful :)
> 
> >>One theory put forward was to have GDB print a banner(6) sized warning 
> >>(and get confirmation) before accepting the option.
> >
> >
> >I have to admit, I don't see the point.  A big warning in the
> >documentation, maybe, but such a confirmation query would drive me
> >crazy if I actually needed to use this regularly.
> 
> That is the point!  I don't want to be around when someone that (shock 
> horror :-) fails to read the manual and then complains that the GDB 
> remote protocol isn't reliable.  What about a:

The only place I documented the syntax is in the manual.  Good luck
finding it otherwise :)

> set remote 
> i-do-not-understand-gdb-remote-protocol-and-foolishly-think-udp-works-so-please-enable-it 
>  on
> 
> option.
> 
> Have you tried running the testsuite across UDP?

Have you tried running the testsuite with gdbserver on a remote
machine? :P  I had to do some severe butchery to DejaGNU, which I'll
clean up as soon as I have time to join the dejagnu list.  Trivial
things worked fine, though.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] Remote UDP support

[Eli Zaretskii]

On Wed, 8 May 2002, Daniel Jacobowitz wrote:

> Here's the matching documentation patch.

Approved.  Thanks.

Re: [RFA] Remote UDP support

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Wed, May 08, 2002 at 10:56:35PM -0400, Andrew Cagney wrote:
> > >>- it wasn't necessary - there are micro tcp implementations around that
> > >>implement sufficient TCP for the remote protocol to work
> > >
> > >
> > >Still bigger than a polled UDP implementation, and much more
> > >complicated.  Implementing a tiny UDP stack is simple!  Sure, it isn't
> > >reliable at all; so use it on small networks and be careful :)
> >
> > >>One theory put forward was to have GDB print a banner(6) sized warning
> > >>(and get confirmation) before accepting the option.
> > >
> > >
> > >I have to admit, I don't see the point.  A big warning in the
> > >documentation, maybe, but such a confirmation query would drive me
> > >crazy if I actually needed to use this regularly.
> >
> > That is the point!  I don't want to be around when someone that (shock
> > horror :-) fails to read the manual and then complains that the GDB
> > remote protocol isn't reliable.  What about a:
> 
> The only place I documented the syntax is in the manual.  Good luck
> finding it otherwise :)

"help target remote"?

> > set remote
> > i-do-not-understand-gdb-remote-protocol-and-foolishly-think-udp-works-so-please-enable-it
> >  on
> >
> > option.
> >
> > Have you tried running the testsuite across UDP?
> 
> Have you tried running the testsuite with gdbserver on a remote
> machine? :P  

Yes, it was certainly working some time (recently too, I think).
Have you looked at testsuite/config/gdbserver.exp?

Re: [RFA] Remote UDP support

[Daniel Jacobowitz]

On Thu, May 09, 2002 at 11:23:45AM -0700, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> > 
> > On Wed, May 08, 2002 at 10:56:35PM -0400, Andrew Cagney wrote:
> > > >>- it wasn't necessary - there are micro tcp implementations around that
> > > >>implement sufficient TCP for the remote protocol to work
> > > >
> > > >
> > > >Still bigger than a polled UDP implementation, and much more
> > > >complicated.  Implementing a tiny UDP stack is simple!  Sure, it isn't
> > > >reliable at all; so use it on small networks and be careful :)
> > >
> > > >>One theory put forward was to have GDB print a banner(6) sized warning
> > > >>(and get confirmation) before accepting the option.
> > > >
> > > >
> > > >I have to admit, I don't see the point.  A big warning in the
> > > >documentation, maybe, but such a confirmation query would drive me
> > > >crazy if I actually needed to use this regularly.
> > >
> > > That is the point!  I don't want to be around when someone that (shock
> > > horror :-) fails to read the manual and then complains that the GDB
> > > remote protocol isn't reliable.  What about a:
> > 
> > The only place I documented the syntax is in the manual.  Good luck
> > finding it otherwise :)
> 
> "help target remote"?

I didn't add it; I probably ought to.

Andrew, would you be satisfied with a warning in the manual and a
warning in 'help target remote'?

> > > set remote
> > > i-do-not-understand-gdb-remote-protocol-and-foolishly-think-udp-works-so-please-enable-it
> > >  on
> > >
> > > option.
> > >
> > > Have you tried running the testsuite across UDP?
> > 
> > Have you tried running the testsuite with gdbserver on a remote
> > machine? :P  
> 
> Yes, it was certainly working some time (recently too, I think).
> Have you looked at testsuite/config/gdbserver.exp?

That works for testing with gdbserver on the _local_ machine.  Note
that it uses remote_spawn "host" to start gdbserver, and does not copy
the binary to target.  I'll submit a patch once I sort out the changes
that I needed to make to dejagnu/lib/remote.exp.

It also does not work on the MI tests; I've submitted a patch and filed a
GNATS PR about this some time ago.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] Remote UDP support

[Andrew Cagney]

> Andrew, would you be satisfied with a warning in the manual and a
> warning in 'help target remote'?

No.  I think it need to be in the users face.  I don't think GDB should 
silently let the user to use a broken mechanism.

Andrew

Re: [RFA] Remote UDP support

[Daniel Jacobowitz]

On Thu, May 09, 2002 at 05:18:02PM -0400, Andrew Cagney wrote:
> >Andrew, would you be satisfied with a warning in the manual and a
> >warning in 'help target remote'?
> 
> No.  I think it need to be in the users face.  I don't think GDB should 
> silently let the user to use a broken mechanism.

I really don't agree, but your call.  Could I at least persuade you
down to a one-line warning and no confirmation query?

Requiring a separate confirmation just seems like a bad interface
decision.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] Remote UDP support

[Andrew Cagney]

> On Thu, May 09, 2002 at 05:18:02PM -0400, Andrew Cagney wrote:
> 
>> >Andrew, would you be satisfied with a warning in the manual and a
>> >warning in 'help target remote'?
> 
>> 
>> No.  I think it need to be in the users face.  I don't think GDB should 
>> silently let the user to use a broken mechanism.
> 
> 
> I really don't agree, but your call.  Could I at least persuade you
> down to a one-line warning and no confirmation query?
> 
> Requiring a separate confirmation just seems like a bad interface
> decision.

It is relative.  Adding a feature to GDB that will make GDB unreliable 
and then failing to alert the user of the consequences is, I think, a 
worse decision.  The user is no longer able to depend on the debuger - 
something critically important for someone debugging an embedded 
application.

Can you please update the patch to include a mechanism for querying the 
user (just the first time) to confirm that they know and understand that 
the mechanism is unreliable (including a brief statement of known 
failure states).

enjoy,
Andrew

Re: [RFA] Remote UDP support

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> > On Thu, May 09, 2002 at 05:18:02PM -0400, Andrew Cagney wrote:
> >
> >> >Andrew, would you be satisfied with a warning in the manual and a
> >> >warning in 'help target remote'?
> >
> >> No.  I think it need to be in the users face.  I don't think GDB
> >> should silently let the user to use a broken mechanism.
> > I really don't agree, but your call.  Could I at least persuade you
> > down to a one-line warning and no confirmation query?
> > Requiring a separate confirmation just seems like a bad interface
> > decision.
> 
> It is relative.  Adding a feature to GDB that will make GDB unreliable
> and then failing to alert the user of the consequences is, I think, a
> worse decision.  The user is no longer able to depend on the debuger -
> something critically important for someone debugging an embedded
> application.
> 
> Can you please update the patch to include a mechanism for querying
> the user (just the first time) to confirm that they know and
> understand that the mechanism is unreliable (including a brief
> statement of known failure states).

I really disagree with this.  It's fine to print a one-line warning
--- something that doesn't interrupt the user's train of thought.  But
people aren't going to type "target remote udp:..." by accident.

Whenever I've said, "UDP isn't reliable!", nobody has ever reacted
with shock --- "You're kidding!  It isn't?"  They always say, "Yes, I
know, and I don't care."

Re: [RFA] Remote UDP support

[Jason R Thorpe]

On Thu, May 09, 2002 at 10:51:39PM -0500, Jim Blandy wrote:

 > Whenever I've said, "UDP isn't reliable!", nobody has ever reacted
 > with shock --- "You're kidding!  It isn't?"  They always say, "Yes, I
 > know, and I don't care."

Indeed.  NetBSD supports a remote UDP protocol for kernel debugging, and
everyone who uses it pretty much doesn't care that UDP is not a reliable
protocol.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

Re: [RFA] Remote UDP support

[Andrew Cagney]

> I really disagree with this.  It's fine to print a one-line warning
> --- something that doesn't interrupt the user's train of thought.  But
> people aren't going to type "target remote udp:..." by accident.
> 
> Whenever I've said, "UDP isn't reliable!", nobody has ever reacted
> with shock --- "You're kidding!  It isn't?"  They always say, "Yes, I
> know, and I don't care."

I think there is a subtle difference between someone understanding that 
``UDP is unreliable'' and someone understanding that the remote protocol 
doesn't work across UDP.

Take for instance, TFTP.  Everyone knows that TFTP uses good old 
unreliable UDP but hey that still works, right?  It just means that it 
has the occasional hickup.

GDB's remote protocol can't come close to meeting even that expecation. 
  Drop a packet and the session can die.

BTW, anyone thought to try typing in ``tiny tcp stack'' in a search engine?

enjoy,
Andrew

Re: [RFA] Remote UDP support

[Jason R Thorpe]

On Fri, May 10, 2002 at 12:45:55AM -0400, Andrew Cagney wrote:

 > BTW, anyone thought to try typing in ``tiny tcp stack'' in a search engine?

I actually have a copy of a tiny TCP stack somewhere.  It's the one
posted to Usenet by Imagen several eons ago.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

Re: [RFA] Remote UDP support

[Frank Ch. Eigler]

cagney wrote:

> [...]
> I think there is a subtle difference between someone understanding
> that ``UDP is unreliable'' and someone understanding that the remote
> protocol doesn't work across UDP.
> [...]

It seems that this train of thought indicates a self-contradictory
attitude.  Either the remote protocol is "good enough" over udp, or it
isn't.  If on one hand you think it's good enough to be included
within mainline gdb, then don't argue that it's not good enough to
actually work.

Besides, the failure scenarios described due to UDP can equally happen
over other transports, due to failures on the host / target.  It would
be wiser to tighten up gdb's and targets' handling of such conditions
(with more clever timeout and error handling, synchronization
recovery) than focus so much on UDP.


- FChE

Re: [RFA] Remote UDP support

[Andrew Cagney]

> cagney wrote:
> 
> 
>> [...]
>> I think there is a subtle difference between someone understanding
>> that ``UDP is unreliable'' and someone understanding that the remote
>> protocol doesn't work across UDP.
>> [...]
> 
> 
> It seems that this train of thought indicates a self-contradictory
> attitude.  Either the remote protocol is "good enough" over udp, or it
> isn't.  If on one hand you think it's good enough to be included
> within mainline gdb, then don't argue that it's not good enough to
> actually work.

Not really.

UDP across the loopback interface is 100% reliable.  Across cheap 
overloaded thin-wire definitly isn't.  A judgement call regarding 
suitability is required, however the user making the decision needs to 
be fully informed.

Andrew

Re: [RFA] Remote UDP support

[Jason R Thorpe]

On Fri, May 10, 2002 at 04:54:21PM -0400, Andrew Cagney wrote:

 > UDP across the loopback interface is 100% reliable.  Across cheap 

It is? :-)

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

Re: [RFA] Remote UDP support

[Martin M. Hunt]

On Friday 10 May 2002 01:54 pm, Andrew Cagney wrote:
> > cagney wrote:
> >> [...]
> >> I think there is a subtle difference between someone understanding
> >> that ``UDP is unreliable'' and someone understanding that the remote
> >> protocol doesn't work across UDP.
> >> [...]
> >
> > It seems that this train of thought indicates a self-contradictory
> > attitude.  Either the remote protocol is "good enough" over udp, or it
> > isn't.  If on one hand you think it's good enough to be included
> > within mainline gdb, then don't argue that it's not good enough to
> > actually work.
>
> Not really.
>
> UDP across the loopback interface is 100% reliable.  Across cheap
> overloaded thin-wire definitly isn't.  

Not true, but not important.

I don't understand what the fuss is about.  The "users" for UDP are not 
clueless people who are going to accidently connect to a target with UDP.  
They are probably embedded engineers trying to get new hardware running with 
GDB ASAP. So warn them, but there is no reason to harrass them.

-- 
Martin Hunt
GDB Engineer
Red Hat, Inc.

Re: [RFA] Remote UDP support

[Andrew Cagney]

> No.  I think it need to be in the users face.  I don't think GDB should 
>> silently let the user to use a broken mechanism.
> 
> 
> I really don't agree, but your call.  Could I at least persuade you
> down to a one-line warning and no confirmation query?

Oh! All right then :-)

Andrew

Re: [RFA] Remote UDP support

[Daniel Jacobowitz]

On Sat, May 11, 2002 at 03:13:02PM -0400, Andrew Cagney wrote:
> >No.  I think it need to be in the users face.  I don't think GDB should 
> >>silently let the user to use a broken mechanism.
> >
> >
> >I really don't agree, but your call.  Could I at least persuade you
> >down to a one-line warning and no confirmation query?
> 
> Oh! All right then :-)

How's this look?  I wasn't quite sure what to put in the text of the
warning.  Also added one to the manual.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Index: ser-tcp.c
===================================================================
RCS file: /cvs/src/src/gdb/ser-tcp.c,v
retrieving revision 1.10
diff -u -p -r1.10 ser-tcp.c
--- ser-tcp.c	18 Dec 2001 18:54:18 -0000	1.10
+++ ser-tcp.c	11 May 2002 21:19:41 -0000
@@ -38,12 +38,15 @@
 #include <netdb.h>
 #include <sys/socket.h>
 #include <netinet/tcp.h>
+#include <netinet/udp.h>
 
 #include <signal.h>
 #include "gdb_string.h"
 
-static int tcp_open (struct serial *scb, const char *name);
-static void tcp_close (struct serial *scb);
+static int udp_warning = 0;
+
+static int net_open (struct serial *scb, const char *name);
+static void net_close (struct serial *scb);
 extern int (*ui_loop_hook) (int);
 void _initialize_ser_tcp (void);
 
@@ -55,17 +58,35 @@ void _initialize_ser_tcp (void);
 /* Open a tcp socket */
 
 static int
-tcp_open (struct serial *scb, const char *name)
+net_open (struct serial *scb, const char *name)
 {
   char *port_str, hostname[100];
   int n, port, tmp;
+  int use_udp;
   struct hostent *hostent;
   struct sockaddr_in sockaddr;
 
+  use_udp = 0;
+  if (strncmp (name, "udp:", 4) == 0)
+    {
+      use_udp = 1;
+      name = name + 4;
+
+      if (udp_warning == 0)
+	{
+	  udp_warning = 1;
+	  warning ("UDP debugging is unreliable.");
+	  warning ("Some events may be lost, rendering further debugging "
+		   "impossible.");
+	}
+    }
+  else if (strncmp (name, "tcp:", 4) == 0)
+    name = name + 4;
+
   port_str = strchr (name, ':');
 
   if (!port_str)
-    error ("tcp_open: No colon in host name!");	   /* Shouldn't ever happen */
+    error ("net_open: No colon in host name!");	   /* Shouldn't ever happen */
 
   tmp = min (port_str - name, (int) sizeof hostname - 1);
   strncpy (hostname, name, tmp);	/* Don't want colon */
@@ -84,7 +105,11 @@ tcp_open (struct serial *scb, const char
       return -1;
     }
 
-  scb->fd = socket (PF_INET, SOCK_STREAM, 0);
+  if (use_udp)
+    scb->fd = socket (PF_INET, SOCK_DGRAM, 0);
+  else
+    scb->fd = socket (PF_INET, SOCK_STREAM, 0);
+
   if (scb->fd < 0)
     return -1;
   
@@ -102,7 +127,7 @@ tcp_open (struct serial *scb, const char
 
   if (n < 0 && errno != EINPROGRESS)
     {
-      tcp_close (scb);
+      net_close (scb);
       return -1;
     }
 
@@ -124,7 +149,7 @@ tcp_open (struct serial *scb, const char
 	      if (ui_loop_hook (0))
 		{
 		  errno = EINTR;
-		  tcp_close (scb);
+		  net_close (scb);
 		  return -1;
 		}
 	    }
@@ -142,7 +167,7 @@ tcp_open (struct serial *scb, const char
 	{
 	  if (polls > TIMEOUT * POLL_INTERVAL)
 	    errno = ETIMEDOUT;
-	  tcp_close (scb);
+	  net_close (scb);
 	  return -1;
 	}
     }
@@ -156,20 +181,23 @@ tcp_open (struct serial *scb, const char
       {
 	if (err)
 	  errno = err;
-	tcp_close (scb);
+	net_close (scb);
 	return -1;
       }
   } 
-  
+
   /* turn off nonblocking */
   tmp = 0;
   ioctl (scb->fd, FIONBIO, &tmp);
 
-  /* Disable Nagle algorithm. Needed in some cases. */
-  tmp = 1;
-  setsockopt (scb->fd, IPPROTO_TCP, TCP_NODELAY,
-	      (char *)&tmp, sizeof (tmp));
-  
+  if (use_udp == 0)
+    {
+      /* Disable Nagle algorithm. Needed in some cases. */
+      tmp = 1;
+      setsockopt (scb->fd, IPPROTO_TCP, TCP_NODELAY,
+		  (char *)&tmp, sizeof (tmp));
+    }
+
   /* If we don't do this, then GDB simply exits
      when the remote side dies.  */
   signal (SIGPIPE, SIG_IGN);
@@ -178,7 +206,7 @@ tcp_open (struct serial *scb, const char
 }
 
 static void
-tcp_close (struct serial *scb)
+net_close (struct serial *scb)
 {
   if (scb->fd < 0)
     return;
@@ -194,8 +222,8 @@ _initialize_ser_tcp (void)
   memset (ops, sizeof (struct serial_ops), 0);
   ops->name = "tcp";
   ops->next = 0;
-  ops->open = tcp_open;
-  ops->close = tcp_close;
+  ops->open = net_open;
+  ops->close = net_close;
   ops->readchar = ser_unix_readchar;
   ops->write = ser_unix_write;
   ops->flush_output = ser_unix_nop_flush_output;
Index: doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.98
diff -u -p -r1.98 gdb.texinfo
--- doc/gdb.texinfo	4 May 2002 16:00:30 -0000	1.98
+++ doc/gdb.texinfo	11 May 2002 21:21:23 -0000
@@ -10475,7 +10475,7 @@ of its pure text.
 Establish communication using the @code{target remote} command.
 Its argument specifies how to communicate with the target
 machine---either via a devicename attached to a direct serial line, or a
-TCP port (usually to a terminal server which in turn has a serial line
+TCP or UDP port (usually to a terminal server which in turn has a serial line
 to the target).  For example, to use a serial line connected to the
 device named @file{/dev/ttyb}:
 
@@ -10485,7 +10485,8 @@ target remote /dev/ttyb
 
 @cindex TCP port, @code{target remote}
 To use a TCP connection, use an argument of the form
-@code{@var{host}:port}.  For example, to connect to port 2828 on a
+@code{@var{host}:@var{port}} or @code{tcp:@var{host}:@var{port}}.
+For example, to connect to port 2828 on a
 terminal server named @code{manyfarms}:
 
 @smallexample
@@ -10503,6 +10504,21 @@ target remote :1234
 @noindent
 
 Note that the colon is still required here.
+
+@cindex UDP port, @code{target remote}
+To use a UDP connection, use an argument of the form
+@code{udp:@var{host}:@var{port}}.  For example, to connect to UDP port 2828
+on a terminal server named @code{manyfarms}:
+
+@smallexample
+target remote udp:manyfarms:2828
+@end smallexample
+
+When using a UDP connection for remote debugging, you should keep in mind
+that the `U' stands for ``Unreliable''.  UDP can silently drop packets on
+busy or unreliable networks, which will cause havoc with your debugging
+session.
+
 @end enumerate
 
 Now you can use all the usual commands to examine and change data and to

Re: [RFA] Remote UDP support

[Andrew Cagney]

> On Sat, May 11, 2002 at 03:13:02PM -0400, Andrew Cagney wrote:
> 
>> >No.  I think it need to be in the users face.  I don't think GDB should 
> 
>> >>silently let the user to use a broken mechanism.
> 
>> >
>> >
>> >I really don't agree, but your call.  Could I at least persuade you
>> >down to a one-line warning and no confirmation query?
> 
>> 
>> Oh! All right then :-)
> 
> 
> How's this look?  I wasn't quite sure what to put in the text of the
> warning.  Also added one to the manual.

Problem is, its in the wrong place, and I suspect getting it into the 
right place - remote.c - is tricky.

I think adding a FIXME hack to remote.c (search for serial_open) that 
checks for ``udp:'' and then print a warning is the most pratical.

Andrew

Re: [RFA] Remote UDP support

[Daniel Jacobowitz]

On Sat, May 11, 2002 at 06:02:03PM -0400, Andrew Cagney wrote:
> >On Sat, May 11, 2002 at 03:13:02PM -0400, Andrew Cagney wrote:
> >
> >>>No.  I think it need to be in the users face.  I don't think GDB should 
> >
> >>>>silently let the user to use a broken mechanism.
> >
> >>>
> >>>
> >>>I really don't agree, but your call.  Could I at least persuade you
> >>>down to a one-line warning and no confirmation query?
> >
> >>
> >>Oh! All right then :-)
> >
> >
> >How's this look?  I wasn't quite sure what to put in the text of the
> >warning.  Also added one to the manual.
> 
> Problem is, its in the wrong place, and I suspect getting it into the 
> right place - remote.c - is tricky.
> 
> I think adding a FIXME hack to remote.c (search for serial_open) that 
> checks for ``udp:'' and then print a warning is the most pratical.

I don't understand.  Why hoist it up into remote.c, before each call to
serial_open?  That just descends through serial_open to call net_open
and the warning would arrive at the same position; the warning is
specific to ser-tcp, and seems to belong there.

Perhaps if you explain what you're trying to accomplish by having it
somewhere else.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] Remote UDP support

[Andrew Cagney]

> How's this look?  I wasn't quite sure what to put in the text of the
>> >warning.  Also added one to the manual.
> 
>> 
>> Problem is, its in the wrong place, and I suspect getting it into the 
>> right place - remote.c - is tricky.
>> 
>> I think adding a FIXME hack to remote.c (search for serial_open) that 
>> checks for ``udp:'' and then print a warning is the most pratical.
> 
> 
> I don't understand.  Why hoist it up into remote.c, before each call to
> serial_open?  That just descends through serial_open to call net_open
> and the warning would arrive at the same position; the warning is
> specific to ser-tcp, and seems to belong there.

Sorry, yes the rationale was a big bit vague :-(

serial_open() provides a generic serial connection. Data that goes in 
one end, hopefully, comes out the other end - it doesn't promise to be 
reliable though.

remote.c, on the other hand, makes certain assumptions about the 
properties of the SERIAL object it is using (only data overrun is 
possible, single character transfers are reliable, ...).  Hence, I think 
remote.c should be the one reporting a potential problem.

Besides, if someone were to implement a remote-udp.c the warning would 
be wrong :-)

enjoy,
Andrew

Re: [RFA] Remote UDP support

[Daniel Jacobowitz]

On Mon, May 13, 2002 at 12:44:15AM -0400, Andrew Cagney wrote:
> >How's this look?  I wasn't quite sure what to put in the text of the
> >>>warning.  Also added one to the manual.
> >
> >>
> >>Problem is, its in the wrong place, and I suspect getting it into the 
> >>right place - remote.c - is tricky.
> >>
> >>I think adding a FIXME hack to remote.c (search for serial_open) that 
> >>checks for ``udp:'' and then print a warning is the most pratical.
> >
> >
> >I don't understand.  Why hoist it up into remote.c, before each call to
> >serial_open?  That just descends through serial_open to call net_open
> >and the warning would arrive at the same position; the warning is
> >specific to ser-tcp, and seems to belong there.
> 
> Sorry, yes the rationale was a big bit vague :-(
> 
> serial_open() provides a generic serial connection. Data that goes in 
> one end, hopefully, comes out the other end - it doesn't promise to be 
> reliable though.
> 
> remote.c, on the other hand, makes certain assumptions about the 
> properties of the SERIAL object it is using (only data overrun is 
> possible, single character transfers are reliable, ...).  Hence, I think 
> remote.c should be the one reporting a potential problem.
> 
> Besides, if someone were to implement a remote-udp.c the warning would 
> be wrong :-)

OK, that did it.  Now I understand why you wanted it.  Is this better?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

2002-05-08  Daniel Jacobowitz  <drow@mvista.com>

	* ser-tcp.c: Include <netinet/udp.h>.  Rename tcp_open
	and tcp_close to net_open and net_close.
	(net_open): Accept "udp:" and "tcp:" specifications.  Connect
	using UDP if requested.  Don't try to disable Nagle on UDP
	sockets.
	* remote.c (remote_serial_open): New function.  Warn about UDP.
	(remote_open_1, remote_async_open_1, remote_cisco_open): Call it.

2002-05-08  Daniel Jacobowitz  <drow@mvista.com>

	* gdb.texinfo (Debug Session): Document new `udp:' and `tcp:'
	options for `target remote'.

Index: remote.c
===================================================================
RCS file: /cvs/src/src/gdb/remote.c,v
retrieving revision 1.80
diff -u -p -r1.80 remote.c
--- remote.c	12 May 2002 01:02:58 -0000	1.80
+++ remote.c	13 May 2002 16:34:59 -0000
@@ -2222,6 +2222,26 @@ remote_check_symbols (struct objfile *ob
     }
 }
 
+static struct serial *
+remote_serial_open (char *name)
+{
+  static int udp_warning = 0;
+
+  /* FIXME: Parsing NAME here is a hack.  But we want to warn here instead
+     of in ser-tcp.c, because it is the remote protocol assuming that the
+     serial connection is reliable and not the serial connection promising
+     to be.  */
+  if (!udp_warning && strncmp (name, "udp:", 4) == 0)
+    {
+      warning ("The remote protocol may be unreliable over UDP.");
+      warning ("Some events may be lost, rendering further debugging "
+	       "impossible.");
+      udp_warning = 1;
+    }
+
+  return serial_open (name);
+}
+
 static void
 remote_open_1 (char *name, int from_tty, struct target_ops *target,
 	       int extended_p)
@@ -2239,7 +2259,7 @@ remote_open_1 (char *name, int from_tty,
 
   unpush_target (target);
 
-  remote_desc = serial_open (name);
+  remote_desc = remote_serial_open (name);
   if (!remote_desc)
     perror_with_name (name);
 
@@ -2337,7 +2357,7 @@ remote_async_open_1 (char *name, int fro
 
   unpush_target (target);
 
-  remote_desc = serial_open (name);
+  remote_desc = remote_serial_open (name);
   if (!remote_desc)
     perror_with_name (name);
 
@@ -5463,7 +5483,7 @@ remote_cisco_open (char *name, int from_
 
   unpush_target (&remote_cisco_ops);
 
-  remote_desc = serial_open (name);
+  remote_desc = remote_serial_open (name);
   if (!remote_desc)
     perror_with_name (name);
 
Index: ser-tcp.c
===================================================================
RCS file: /cvs/src/src/gdb/ser-tcp.c,v
retrieving revision 1.10
diff -u -p -r1.10 ser-tcp.c
--- ser-tcp.c	18 Dec 2001 18:54:18 -0000	1.10
+++ ser-tcp.c	13 May 2002 16:34:59 -0000
@@ -38,12 +38,13 @@
 #include <netdb.h>
 #include <sys/socket.h>
 #include <netinet/tcp.h>
+#include <netinet/udp.h>
 
 #include <signal.h>
 #include "gdb_string.h"
 
-static int tcp_open (struct serial *scb, const char *name);
-static void tcp_close (struct serial *scb);
+static int net_open (struct serial *scb, const char *name);
+static void net_close (struct serial *scb);
 extern int (*ui_loop_hook) (int);
 void _initialize_ser_tcp (void);
 
@@ -55,17 +56,27 @@ void _initialize_ser_tcp (void);
 /* Open a tcp socket */
 
 static int
-tcp_open (struct serial *scb, const char *name)
+net_open (struct serial *scb, const char *name)
 {
   char *port_str, hostname[100];
   int n, port, tmp;
+  int use_udp;
   struct hostent *hostent;
   struct sockaddr_in sockaddr;
 
+  use_udp = 0;
+  if (strncmp (name, "udp:", 4) == 0)
+    {
+      use_udp = 1;
+      name = name + 4;
+    }
+  else if (strncmp (name, "tcp:", 4) == 0)
+    name = name + 4;
+
   port_str = strchr (name, ':');
 
   if (!port_str)
-    error ("tcp_open: No colon in host name!");	   /* Shouldn't ever happen */
+    error ("net_open: No colon in host name!");	   /* Shouldn't ever happen */
 
   tmp = min (port_str - name, (int) sizeof hostname - 1);
   strncpy (hostname, name, tmp);	/* Don't want colon */
@@ -84,7 +95,11 @@ tcp_open (struct serial *scb, const char
       return -1;
     }
 
-  scb->fd = socket (PF_INET, SOCK_STREAM, 0);
+  if (use_udp)
+    scb->fd = socket (PF_INET, SOCK_DGRAM, 0);
+  else
+    scb->fd = socket (PF_INET, SOCK_STREAM, 0);
+
   if (scb->fd < 0)
     return -1;
   
@@ -102,7 +117,7 @@ tcp_open (struct serial *scb, const char
 
   if (n < 0 && errno != EINPROGRESS)
     {
-      tcp_close (scb);
+      net_close (scb);
       return -1;
     }
 
@@ -124,7 +139,7 @@ tcp_open (struct serial *scb, const char
 	      if (ui_loop_hook (0))
 		{
 		  errno = EINTR;
-		  tcp_close (scb);
+		  net_close (scb);
 		  return -1;
 		}
 	    }
@@ -142,7 +157,7 @@ tcp_open (struct serial *scb, const char
 	{
 	  if (polls > TIMEOUT * POLL_INTERVAL)
 	    errno = ETIMEDOUT;
-	  tcp_close (scb);
+	  net_close (scb);
 	  return -1;
 	}
     }
@@ -156,20 +171,23 @@ tcp_open (struct serial *scb, const char
       {
 	if (err)
 	  errno = err;
-	tcp_close (scb);
+	net_close (scb);
 	return -1;
       }
   } 
-  
+
   /* turn off nonblocking */
   tmp = 0;
   ioctl (scb->fd, FIONBIO, &tmp);
 
-  /* Disable Nagle algorithm. Needed in some cases. */
-  tmp = 1;
-  setsockopt (scb->fd, IPPROTO_TCP, TCP_NODELAY,
-	      (char *)&tmp, sizeof (tmp));
-  
+  if (use_udp == 0)
+    {
+      /* Disable Nagle algorithm. Needed in some cases. */
+      tmp = 1;
+      setsockopt (scb->fd, IPPROTO_TCP, TCP_NODELAY,
+		  (char *)&tmp, sizeof (tmp));
+    }
+
   /* If we don't do this, then GDB simply exits
      when the remote side dies.  */
   signal (SIGPIPE, SIG_IGN);
@@ -178,7 +196,7 @@ tcp_open (struct serial *scb, const char
 }
 
 static void
-tcp_close (struct serial *scb)
+net_close (struct serial *scb)
 {
   if (scb->fd < 0)
     return;
@@ -194,8 +212,8 @@ _initialize_ser_tcp (void)
   memset (ops, sizeof (struct serial_ops), 0);
   ops->name = "tcp";
   ops->next = 0;
-  ops->open = tcp_open;
-  ops->close = tcp_close;
+  ops->open = net_open;
+  ops->close = net_close;
   ops->readchar = ser_unix_readchar;
   ops->write = ser_unix_write;
   ops->flush_output = ser_unix_nop_flush_output;
Index: doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.98
diff -u -p -r1.98 gdb.texinfo
--- doc/gdb.texinfo	4 May 2002 16:00:30 -0000	1.98
+++ doc/gdb.texinfo	13 May 2002 16:35:22 -0000
@@ -10475,7 +10475,7 @@ of its pure text.
 Establish communication using the @code{target remote} command.
 Its argument specifies how to communicate with the target
 machine---either via a devicename attached to a direct serial line, or a
-TCP port (usually to a terminal server which in turn has a serial line
+TCP or UDP port (usually to a terminal server which in turn has a serial line
 to the target).  For example, to use a serial line connected to the
 device named @file{/dev/ttyb}:
 
@@ -10485,7 +10485,8 @@ target remote /dev/ttyb
 
 @cindex TCP port, @code{target remote}
 To use a TCP connection, use an argument of the form
-@code{@var{host}:port}.  For example, to connect to port 2828 on a
+@code{@var{host}:@var{port}} or @code{tcp:@var{host}:@var{port}}.
+For example, to connect to port 2828 on a
 terminal server named @code{manyfarms}:
 
 @smallexample
@@ -10503,6 +10504,21 @@ target remote :1234
 @noindent
 
 Note that the colon is still required here.
+
+@cindex UDP port, @code{target remote}
+To use a UDP connection, use an argument of the form
+@code{udp:@var{host}:@var{port}}.  For example, to connect to UDP port 2828
+on a terminal server named @code{manyfarms}:
+
+@smallexample
+target remote udp:manyfarms:2828
+@end smallexample
+
+When using a UDP connection for remote debugging, you should keep in mind
+that the `U' stands for ``Unreliable''.  UDP can silently drop packets on
+busy or unreliable networks, which will cause havoc with your debugging
+session.
+
 @end enumerate
 
 Now you can use all the usual commands to examine and change data and to

Re: [RFA] Remote UDP support

[Andrew Cagney]

> 2002-05-08  Daniel Jacobowitz  <drow@mvista.com>
> 
> 	* ser-tcp.c: Include <netinet/udp.h>.  Rename tcp_open
> 	and tcp_close to net_open and net_close.
> 	(net_open): Accept "udp:" and "tcp:" specifications.  Connect
> 	using UDP if requested.  Don't try to disable Nagle on UDP
> 	sockets.
> 	* remote.c (remote_serial_open): New function.  Warn about UDP.
> 	(remote_open_1, remote_async_open_1, remote_cisco_open): Call it.
> 

Yes, thanks.
Andrew

Re: [RFA] Remote UDP support

[Daniel Jacobowitz]

On Mon, May 13, 2002 at 05:06:53PM -0400, Andrew Cagney wrote:
> >2002-05-08  Daniel Jacobowitz  <drow@mvista.com>
> >
> >	* ser-tcp.c: Include <netinet/udp.h>.  Rename tcp_open
> >	and tcp_close to net_open and net_close.
> >	(net_open): Accept "udp:" and "tcp:" specifications.  Connect
> >	using UDP if requested.  Don't try to disable Nagle on UDP
> >	sockets.
> >	* remote.c (remote_serial_open): New function.  Warn about UDP.
> >	(remote_open_1, remote_async_open_1, remote_cisco_open): Call it.
> >
> 
> Yes, thanks.
> Andrew

Glad we could come to an agreement :)  It's in.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer