Re: MI testsuite improvements

["Alain Magloire" <alain@qnx.com>]

> 
> 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.