How do I detect child input?
Rich Title
richt at breakpoint.ksr.com
Sat Sep 2 04:37:20 AEST 1989
In article <469 at telesoft.telesoft.com> jjh at telesoft.telesoft.com (Jim Hayes @wayward) writes:
>
>Hi all,
>
> I'm working on a source-level debugger which runs on a Sun3 using SunOS 4.0.
>We spawn the target program (the program being debugged) using vfork(2) and keep
>control over it using ptrace(2). We want to have complete control over the
>child's terminal input and output so we can direct it to an i/o window we've
>set up; in order to do this we replace the child's stdin, stdout, and stderr
>descriptors with one end of a pipe, the other end of which the debugger watches.
>This works fine for the child's output: we check the pipe periodically using
>fstat(2), and when the child writes something onto the pipe we read it and
>display it to the window. But I sure can't figure out how to detect when the
>child is waiting for input. Right now we make the assumption that anything the
>user types while the child is running is intended for the child, and we send it
>down the pipe. This works ok, but it's not "right" and has several problems
>associated with it. Any suggestions?
>
>--Jim
I'm trying to figure out why you need to make the assumption you're making.
Perhaps it's a limitation of the windowing system you're using - you can't
collect input from the target i/o window (?), so you have to collect it
from the debugger's stdin (?), so you have to make this assumption in order
to figure out what input goes to the debugger and what input goes to
the target program?
Anyway, here's what I do in my debugger. This assumes you're using
X-windows, so it may or may not help you...
1. Use "xterm" in slave mode as the program I/O window.
When the user selects this window and
types at it, that input goes to the target program (doesn't matter
whether the target program was running at the time). When the target
program writes output, it goes to this window.
Using a terminal emulator such as "xterm" as the target window
also has the advantage of working properly even if the target
program does screen-oriented things (e.g., uses 'curses').
2. Use pty's to transfer I/O between the target window and the target
program. That way, the debugger doesn't have to sit in the middle
watching file descriptors.
In more detail:
- Allocate a pty (see pty(4)). In other words, open the pair of files
/dev/pty[p-r][0-f] and /dev/tty[p-r][0-f]. For example, /dev/ptyq3
and /dev/ttyq3. This gives you two file descriptors. Just for the
sake of example, let's say these are file descriptors 5 and 6.
- For the program I/O window, run 'xterm' in slave mode. I.e., you
fork a process and exec "xterm" in that process. Give "xterm" the
switch "-Sccn" where 'cc' is the 2 characters indicating
what pty you are using, and 'n' is
a number representing the pty file descriptor. So using the above
example, you would run "xterm -Sq35 ...".
- Then, when you fork the child process, before exec-ing the
program being debugged, dup the
tty file descriptor (6 in the above example), to 0, 1, and 2.
The effect of all this is that input and output to the xterm appears
as input/output on the tty file descriptor, which to the program
being debugged is just the ordinary stdin, stdout, stderr.
- Rich
More information about the Comp.unix.wizards
mailing list