Re: problems with v3
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. Ah, I see. I've appended the patch I came up with. I have not tried it at all, but it should all be pretty obvious. Yeah, that seems like it should be reasonable, i.e. more or less like what I'd figured it would do if it didn't have all these different backends. However, I think the test you probably want is !S_ISCHR. I believe that /proc/ugdb as is stats as S_ISREG, not S_ISFIFO. Actually, better yet, just make it !isatty (fd). Another pseudodevice that also behaves more like a socket than like a tty might be S_ISCHR, but only a tty isatty. Thanks, Roland
Re: problems with v3
Roland However, I think the test you probably want is !S_ISCHR. Thanks. I wasn't sure. Roland Actually, better yet, just make it !isatty (fd). Ok. I made a new branch, 'archer-ugdb'. This patch is there. (Actually 2 patches due to me not reading carefully enough the first time -- but whatever.) Oleg, use this branch and give the feature a try. We can push whatever fixes or hacks you need to this branch. I can also merge from gdb's master as needed. Tom
Re: problems with v3
On 08/13, Tom Tromey wrote: Roland However, I think the test you probably want is !S_ISCHR. Thanks. I wasn't sure. Roland Actually, better yet, just make it !isatty (fd). Ok. Good. IIUC, this also allows to remove the ugly return 0 to pretend TCGETS/TCSETS/TCFLSH works from -ioctl(). I made a new branch, 'archer-ugdb'. I assume, you mean git://sourceware.org/git/gdb.git ? This patch is there. (Actually 2 patches due to me not reading carefully enough the first time -- but whatever.) Oleg, use this branch and give the feature a try. Yes, once I resolve the current problems I'll test it. Thanks! Oleg.
Re: problems with v3 (Was: gdbstub initial code, v3)
I seem to understand the problem(s). I am a bit surprized. Basically I have the questions about almost every utrace_ function. I'll try to recheck and summarize my concerns tomorrow with a fresh head, I hope I missed something. Ok. That stuff about pure kernel implementation issues doesn't need to go to the archer list and Tom, only to utrace-devel. Thanks, Roland
problems with v3 (Was: gdbstub initial code, v3)
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: problems with v3
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
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;
}
