From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12329 invoked by alias); 1 Mar 2005 19:24:17 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 12277 invoked from network); 1 Mar 2005 19:24:12 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sourceware.org with SMTP; 1 Mar 2005 19:24:12 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id OAA06794 for ; Tue, 1 Mar 2005 14:25:21 -0500 Received: (from alain@localhost) by smtp.ott.qnx.com (8.8.8/8.6.12) with UUCP id OAA08836 for gdb-patches@sources.redhat.com; Tue, 1 Mar 2005 14:24:11 -0500 Message-Id: <200503011924.OAA08836@smtp.ott.qnx.com> Subject: Re: MI testsuite improvements To: bob@brasko.net (Bob Rossi) Date: Tue, 01 Mar 2005 19:24:00 -0000 From: "Alain Magloire" Cc: alain@qnx.com (Alain Magloire), cagney@gnu.org (Andrew Cagney), nickrob@snap.net.nz (Nick Roberts), gdb-patches@sources.redhat.com In-Reply-To: <20050301151343.GA29106@white> from "Bob Rossi" at Mar 01, 2005 10:13:43 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2005-03/txt/msg00004.txt.bz2 > > 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.