Re: MI testsuite improvements

Alain Magloire
2005-03-01T19:24:17Z

>
> On Mon, Feb 28, 2005 at 09:40:37PM -0500, Bob Rossi wrote:
> > > > > - The second idea was to have GDB internally create a pty. That would
> > > > > result in a master and slave side. Neither of these are important,
> > > > > AFAIK, only the slavename (file name of the terminal created,
> > > > > ie. /dev/pts/1) is important. For example, here is what could
> > > > > happen
> > > > > 1. The user asks GDB to open a new pty and the name is given back
> > > > > -mi-create-pty
> > > > > /dev/pts/1
> > > > > 2. The user asks GDB to use that pty for the inferior
> > > > > -mi-set-tty /dev/pts/1
> > > > > 3. The user opens /dev/pts/1 in there own program to read the
> > > > > output of the inferior.
> > > > > 4. The user asks GDB to close the device
> > > > > -mi-destroy-pty /dev/pts/1
> > > > >
> > > > > Either way, it will probably be a while before I have time to work on
> > > > > the second task, since I'm already swamped trying to validate the MI
> > > > > testsuite with a syntax checker and changing the grammar to match
> > > > > what GDB actually outputs.
> > >
> > > This is not clear to me ... one more scenario so you can see
> > > from my point of view 8-)
> > >
> > > As you pointed out, when creating the pseudo pty
> > > we have a master and slave side and both should be important :
> > > (gdb) -mi-create-pty
> > > ^done,pty={master="/dev/ptyp0",slave="/dev/ptyTf"}
> > > (gdb)
> > >
> > > The master is given to gdb to set std{in,out,err} of the inferior after forking
> > > (gdb) -mi-set-tty /dev/ptyp0
> > > ^done
> > > (gdb) -exec-run
> > > ^running
> >
> > I didn't even know you could get a device name for the master side. If
> > you have the master fd, you can get the slave name via ptsname, how do
> > you get the master device name?
> >
> > > And the slave is use internally by the front end to read/write when
> > > communicating with the inferior.
> >
> > I have been giving GDB the slave name for the inferior program. Then I
> > also internally read/write using the slave name. Is this wrong? Why are
> > we using different methods?
>
> Please forgive me, I re-thought this.
>
> I get a master fd, a slave fd and a slave device name when I open a new
> pty. I give the slavename to GDB to initialize the inferior. Then, I
> read/write from the master fd. Thus, using both sides of the pty.
>
> I don't know how to get the master device name, is this possible?
>

sigh ... I think it is platform dependent.
For BSD style, it used to be
master: /dev/ptyXY
slave: /dev/ttyXY

meaning the same name except 'p' was change to 't'.

There is a ttyname(3c) but I do not think it works as expected i.e.
it will not return the master name if you do:
ttyname(fd_master);

> One problem is, you give the master device name to GDB for the inferior,
> I give the slave device name. So, we are using the terminal device in
> different directions from the inferior's point of view. This is probably
> not OK. Any ideas or opinion on this?
>

Sorry my confusion, I give gdb the slave pty.

> For instance, I think the terminal semantics is between the slave side and
> the process (inferior) talking to the slave. I think that if the inferior did a
> terminal operation on the slave side, things would act differently than
> if it did a terminal operation on the master side. Or a different
> example, if you send '^u' as the inferior, to the slave side of a pty,
> then I would expect all data on the line to be erased, and data would start
> again at the beggining of the line. However, if the inferior was
> attached to the master side of the pty, I wouldn't expect this to work.
>
> Am I confused here?
>

No.

But even if you do not get the master pty name, this is still usefull for a few reason:

- some programs need, to work correctly, a tty as the input.
- since gdb knows when an output comes from the inferior, you could
wrap any reads coming from the master_fd in an MI Target Stream

* TARGET-STREAM-OUTPUT is the output produced by the target program.
All the target output is prefixed by `@'.
@"Hello worl\n"

This will still help the frontend, one of the major problem, was inferior
outputs were mixed with normal mi outputs.