From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5797 invoked by alias); 17 Feb 2005 16:59:03 -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 5695 invoked from network); 17 Feb 2005 16:58:54 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sourceware.org with SMTP; 17 Feb 2005 16:58:54 -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 MAA08516 for ; Thu, 17 Feb 2005 12:01:20 -0500 Received: (from alain@localhost) by smtp.ott.qnx.com (8.8.8/8.6.12) with UUCP id LAA31041 for gdb-patches@sources.redhat.com; Thu, 17 Feb 2005 11:58:46 -0500 Message-Id: <200502171658.LAA31041@smtp.ott.qnx.com> Subject: Re: MI testsuite improvements To: cagney@gnu.org (Andrew Cagney) Date: Thu, 17 Feb 2005 20:09:00 -0000 From: "Alain Magloire" Cc: alain@qnx.com (Alain Magloire), nickrob@snap.net.nz (Nick Roberts), bob@brasko.net (Bob Rossi), gdb-patches@sources.redhat.com In-Reply-To: <4214AA1D.3030209@gnu.org> from "Andrew Cagney" at Feb 17, 2005 09:28:45 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2005-02/txt/msg00186.txt.bz2 > > Bob Rossi wrote: > > On Wed, Feb 16, 2005 at 09:41:56AM -0500, Andrew Cagney wrote: > > > >>Bob Rossi wrote: > >> > >> > >>>>Let me know what you think. If you want the dbg.log files, I can provide > >>>>them. > >> > >>I was kind of looking for an executive summary :-) I've attached a > >>trimmed diff. > >> > >>Two things: > >> > >>- it should't be using --interpreter console ... > >>Can you and/or: add a new -mi-tty command (+test, +doco) and use that; > >>invoke GDB with the --tty=... option. Your call. Either pre-approved > >>(but get thumbs up from Eli on the doco). > >> > >>- can the TTY output be identified in someway? > >>That might make debugging easier, but if it isn't possible I guess we > >>live with that. > > > > > > OK, I like this idea a lot. I'll make a new mi function that allows you > > to set a tty. I'll also make a new MI function that will allow you to > > retrieve the tty device being used, both GDB and the inferior. > > Ok. Wonder if it should be ``set/show tty'', "tty ..." just a wrapper. > > > Finally, I think it would be helpful to have GDB actually be able to > > create a pty for the front end. In case you didn't know, creating a pty > > can be a non portable task, and GDB should be capable of doing it every > > where it ports to. This would help out the Front Ends a lot. What do you > > think? Something like -mi-tty-new -mi-tty-close? > > I suspect this is correct. > > Alain, how does the CDT currently hande the PTY problem? Would this be > useful? > Yes, it would be. The problem comes from local inferior outputs that are intertwine with MI stream(The remote case is ok since the output is properly wrap in @"..." steam). CDT handles this by creating JNI code per platform that will create a pseudo pty, the slave pty is pass to gdb gdb --tty /dev/ptys/n app And the IDE is reading at the other end of the master and redirecting the outputs to the IDE console widget. Caveats: - Not all platform supports pseudo tty, we still have no solution for Win32/cygwin. - On some platform like Solaris, because the way the suspend is implemented, CTRL-C will no longer work. - When we relaunch/restart, it probably will not work, since the tty is close by the inferior. (Relaunching is important when you have an huge executable .. loading the symbols can be a pain). Now if gdb can create the pty and can give back the master/slave pty so we can redirect the output to the IDE ... that would be perfect making the JNI code obsolete. Sorry, I did not follow Bob's proposals in the mailing list. So maybe I'm completely of track.