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
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; }