Re: gdbstub initial code, v3

[Frank Ch. Eigler]

oleg wrote:

 [...]
   - It doesn't support all-stop mode.
 Please tell me if this is needed. I hope not, this needs
 a lot of nasty complications :/
 [...]

As opposed to non-stop mode?  I'm pretty sure all-stop will be needed
as that is the common  default gdb usage model.


- FChE

problems with v3 (Was: gdbstub initial code, v3)

[Oleg Nesterov]

On 08/11, Tom Tromey wrote:

  Oleg == Oleg Nesterov o...@redhat.com writes:

 Oleg So, the patch below fixes the problem, and gdb + /proc/ugdb seems
 Oleg to work.

 Oleg Indeed, gdb sees that this fd is not pipe/tcp and uses the hardwire
 Oleg serial_ops, but hardwire_readchar() doesn't play well with select().

 Oleg Please teach gdb to use poll/select ?

 I looked at this a little bit.  It seems to me that the hardwire stuff
 is for talking to ttys, and we instead want gdb to be using the pipe code.

I didn't verify this, but I don't think so. Please look at pipe_open().
Perhaps it makes sense to serial_add_interface(ugdb), I dunno.


OK. I was going to add some cleanups and send the new version today.
But after some testing (without gdb) I hit the kernel crashes. This
makes me think that probably something is wrong ;)

As usual, I can't blame my code. I am still investigating, the crash
is not easy to reproduce, but so far I _suspect_ the problems in utrace
code. At least utrace_barrier()-signal_pending() is definitely not
right.

Will continue tomorrow.

Oleg.

Re: gdbstub initial code, v3

[Roland McGrath]

 Indeed, gdb sees that this fd is not pipe/tcp and uses the hardwire
 serial_ops, but hardwire_readchar() doesn't play well with select().
 
 Please teach gdb to use poll/select ?

If it makes it easier, could use:

bash$ nc -l -U /tmp/socket  /proc/ugdb 
(gdb) target remote |nc -U /tmp/socket

for the moment.  Silly of course, but just not to be blocked on cleaning up
gdb's serial-device handling to be more nicely nonblocking.


Thanks,
Roland

Re: problems with v3

[Roland McGrath]

I don't really know the gdb code, but I'm surprised it really has multiple
different serial backends.  I would have thought that after opening the
fd, you would treat them all about the same.  If tcsetattr et al work on
it, then you set the baud rate and whatever, if they say ENOTTY then fine.
It might make sense to default to a short read timeout for an actual serial
port (or UDP port), which might be unplugged or the other end dead, or
whatever; and to an infinite timeout for a non-tty, which should more
presumably have its fd shut down and read EOF or EPIPE or whatever when the
stub goes away, and otherwise perhaps the stub is just taking that long.
But aside from that, I don't know why you wouldn't treat all kinds of
remote protocol fd's the same wrt select/poll and blocking/nonblocking
reads/writes, be they serial-port fds, pipe socketpair sockets, network
sockets, or fds to a new magic file that pretends to be a tty or a socket
or whatever (or even a disk file of canned response playback!).


Thanks,
Roland

Re: problems with v3

[Tom Tromey]

Roland I don't really know the gdb code, but I'm surprised it really
Roland has multiple different serial backends.

I don't know this area well, but considering that ser-unix.c is just
chock full of tty-related goo, I think it is probably important for
something.  My impression is that this API is not just used for target
communication but also for manipulating gdb's own terminal.

I looked closer and aside from open/close, ser-pipe is just falling back
to some generic code.

I've appended the patch I came up with.  I have not tried it at all, but
it should all be pretty obvious.

Maybe I'd do it a little differently if this were going upstream.
That doesn't seem necessary though.

Tom

diff --git a/gdb/ser-unix.c b/gdb/ser-unix.c
index 266453c..672b2a8 100644
--- a/gdb/ser-unix.c
+++ b/gdb/ser-unix.c
@@ -32,6 +32,7 @@
 #include gdb_select.h
 #include gdb_string.h
 #include gdbcmd.h
+#include gdb_stat.h
 
 #ifdef HAVE_TERMIOS
 
@@ -103,15 +104,56 @@ static int hardwire_setstopbits (struct serial *, int);
 
 void _initialize_ser_hardwire (void);
 
+static struct serial_ops *
+get_pipe_like_ops (void)
+{
+  static struct serial_ops *ops;
+  
+  if (ops == NULL)
+{
+  ops = XMALLOC (struct serial_ops);
+  memset (ops, 0, sizeof (struct serial_ops));
+  ops-name = NULL;
+  ops-open = NULL;
+  ops-close = hardwire_close;
+  ops-readchar = ser_base_readchar;
+  ops-write = ser_base_write;
+  ops-flush_output = ser_base_flush_output;
+  ops-flush_input = ser_base_flush_input;
+  ops-send_break = ser_base_send_break;
+  ops-go_raw = ser_base_raw;
+  ops-get_tty_state = ser_base_get_tty_state;
+  ops-set_tty_state = ser_base_set_tty_state;
+  ops-print_tty_state = ser_base_print_tty_state;
+  ops-noflush_set_tty_state = ser_base_noflush_set_tty_state;
+  ops-setbaudrate = ser_base_setbaudrate;
+  ops-setstopbits = ser_base_setstopbits;
+  ops-drain_output = ser_base_drain_output;
+  ops-async = ser_base_async;
+  ops-read_prim = ser_unix_read_prim;
+  ops-write_prim = ser_unix_write_prim;
+}
+
+  return ops;
+}
+
 /* Open up a real live device for serial I/O */
 
 static int
 hardwire_open (struct serial *scb, const char *name)
 {
+  struct stat buf;
+
   scb-fd = open (name, O_RDWR);
   if (scb-fd  0)
 return -1;
 
+  if (fstat (scb-fd, buf) == 0  S_ISFIFO (buf.st_mode))
+{
+  /* Super hack!  */
+  scb-ops = get_pipe_like_ops ();
+}
+
   return 0;
 }