From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6550 invoked by alias); 1 Mar 2005 02:40:44 -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 6407 invoked from network); 1 Mar 2005 02:40:39 -0000 Received: from unknown (HELO lakermmtao05.cox.net) (68.230.240.34) by sourceware.org with SMTP; 1 Mar 2005 02:40:39 -0000 Received: from white ([68.9.64.121]) by lakermmtao05.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050301024033.RGTJ3789.lakermmtao05.cox.net@white>; Mon, 28 Feb 2005 21:40:33 -0500 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1D5xJN-0007MZ-00; Mon, 28 Feb 2005 21:40:37 -0500 Date: Tue, 01 Mar 2005 02:40:00 -0000 From: Bob Rossi To: Alain Magloire Cc: Andrew Cagney , Nick Roberts , gdb-patches@sources.redhat.com Subject: Re: MI testsuite improvements Message-ID: <20050301024037.GA28267@white> Mail-Followup-To: Alain Magloire , Andrew Cagney , Nick Roberts , gdb-patches@sources.redhat.com References: <4218AA55.7080304@gnu.org> <200502221635.LAA07270@smtp.ott.qnx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502221635.LAA07270@smtp.ott.qnx.com> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-03/txt/msg00000.txt.bz2 > > > - 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? Thanks, Bob Rossi