From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21772 invoked by alias); 29 Nov 2010 15:24:54 -0000 Received: (qmail 21757 invoked by uid 22791); 29 Nov 2010 15:24:51 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from imr3.ericy.com (HELO imr3.ericy.com) (198.24.6.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 29 Nov 2010 15:24:45 +0000 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id oATFOYff028344 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Nov 2010 09:24:34 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.63]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 29 Nov 2010 10:24:34 -0500 From: Marc Khouzam To: "'Jan Kratochvil'" CC: "'gdb@sourceware.org'" Date: Mon, 29 Nov 2010 15:24:00 -0000 Subject: RE: Using telnet to control a running GDB Message-ID: References: <20101129025627.GA4356@host0.dyn.jankratochvil.net> In-Reply-To: <20101129025627.GA4356@host0.dyn.jankratochvil.net> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-11/txt/msg00119.txt.bz2 > -----Original Message----- > From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com]=20 > Sent: Sunday, November 28, 2010 9:56 PM > To: Marc Khouzam > Cc: gdb@sourceware.org > Subject: Re: Using telnet to control a running GDB >=20 > On Sun, 28 Nov 2010 19:27:56 +0100, Marc Khouzam wrote: > > The user could ask GDB to open a tcp port which would=20 > accept a telnet connection. > > Using telnet, the user could then start a _second_ shell to=20 > the same GDB and control it. > >=20 > > This would help a user get a full-fledge GDB command shell,=20 > even when GDB > > is being run by a frontend. >=20 > Such shell is present there, isn't it? You have even=20 > provided a fix for it: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D285320 :-) > (eclipse-cdt-6.0.2-5.fc13.x86_64, a bit old, sorry) Click on=20 > Debug window, > line with "gdb" then I can type CLI GDB commands into the=20 > window "Console". > It does not print the GDB prompt there but it works. GDB=20 > gets this command > via MI: > 40-interpreter-exec console "print 1+1"N (N=3D\n) That console is also missing 1- command completion, which we may be able to do using GDB's 'complete' command (thanks Dan for mentioning the command) 2- command history, which will require (I think) to re-implement some of the readline (is that what it is called?) functionality :-( Until that is done, having a telnet session to GDB (if the=20 feature already existed) would have been a workaround for the user. Although, it would probably make the frontend out-of-sync, and it would be harder to fix for the frontend, since it wouldn't be controlling the external GDB shell... Sigh... Maybe this wasn't such a good idea, from the frontend point-of-view. =20 > > It would also allow the remote controlling of a running=20 > GDB. Could be useful > > for troubleshooting. >=20 > When GDB is really running (and not waiting on external=20 > event) it is not > thread safe in general to do anything else in that moment. >=20 > In async (+ non-stop) mode you enabled to be implemented it=20 > should never do > such operation any noticeable time; if it does, GDB should be=20 > fixed (either > for missing async or for performance). I was not thinking of an asynchronous access. Simply a 'duplicate' shell that would behave like the master one. If the master has GDB running and not accepting commands,=20 then the slave(s) would do the same. A simple example would be that I setup a debug session using GDB and things are not behaving as I expect. I call someone to help me look at it. That person would be able to remotely connect to my running instance of GDB and start controlling it, instead of tell me to 'try this command', 'try that command'. I didn't really think of all the implications of this, like if the master shell would show the commands given by the slave(s), for example. But I was curious to know if the feature existed or was ever considered (or rejected :-)) > So it is fully on the front end to provide asynchronous=20 > "Console" window interface, isn't it? In the frontend, we try to mimic the exact user experience provided by the standard GDB shell. But we are still missing features, and need to duplicate much of the functionality ourselves. Thanks marc