Looking for an obscure piece of info

Hi All,

We’re trying to do something that we probably shouldn’t or can’t, but we
still want to understand how it all works anyway.

We’re using GDB with pdebug. Instead of pointing pdebug to a serial port
(/dev/ser1) we’re pointing it to one side of a pty (/dev/ptyp0 for example).
Then on another node, I’m pointing GDB to that other side of that same pty
(/net/node/dev/ttyp0). Thanks to Chris (cdm) and Xiaodan (xtang) for
getting me started with this btw.

The upshot of this of course is that we’re using qnet instead of tcpip for
debugging. “Why?” you may ask, well it’s just that we don’t want to muck
about with IP addresses and the system we’re working on excludes IP anyway.
“Why?” you may ask again…well, “because we want to” would be the answer.
However technically misguided we are doesn’t relieve us of the mystery as to
how a remote process being controlled by pdebug over a pty gets it’s stdin.

When we first started this, it appeared as though the process was getting
stdin just fine…then, all of a sudden it stops working, it won’t take
input from the gdb session like it did in the past. I had the program
(after it stopped working of course) print out “ttyname( 0 )” and it reports
/dev/ttyp0 or /dev/ttyp1, but we have yet to make a correlation between that
and the terminal from which gdb is getting it stdin.

We also played around with GDB’s ‘tty’ command but that didn’t seem to do

In any case, we think it boils down to one thing…does a remote process
being debugged over a serial line get stdin from the GDB console
(transmitted over the serial line) ? If so, how can it get cut off (which
options affect the routing of stdin to a remote process over a serial port).
If we knew the answer to this, maybe it would apply to pty’s being used as
if they were serial ports.

Well…thanks for indulging us by reading this nonsense…if you have any
ideas, a couple of guys trying to do weird things with the dev environment
would be appreciative.



oops…please forgive me…this should be in qnxtrp.devtools…