From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1679 invoked by alias); 29 Nov 2010 20:00:59 -0000 Received: (qmail 1670 invoked by uid 22791); 29 Nov 2010 20:00:58 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from imr4.ericy.com (HELO imr4.ericy.com) (198.24.6.8) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 29 Nov 2010 20:00:51 +0000 Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id oATKSGw9004443; Mon, 29 Nov 2010 14:28:22 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.63]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 29 Nov 2010 15:00:36 -0500 From: Marc Khouzam To: "'Jan Kratochvil'" CC: "'gdb@sourceware.org'" Date: Mon, 29 Nov 2010 20:00:00 -0000 Subject: RE: Using telnet to control a running GDB Message-ID: References: <20101129025627.GA4356@host0.dyn.jankratochvil.net> <20101129185524.GA13721@host0.dyn.jankratochvil.net> In-Reply-To: <20101129185524.GA13721@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/msg00126.txt.bz2 > -----Original Message----- > From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com]=20 > Sent: Monday, November 29, 2010 1:55 PM > To: Marc Khouzam > Cc: 'gdb@sourceware.org' > Subject: Re: Using telnet to control a running GDB >=20 > On Mon, 29 Nov 2010 16:24:32 +0100, Marc Khouzam wrote: > > Until that is done, having a telnet session to GDB (if the=20 > > feature already existed) would have been a workaround for the user. >=20 > GDB is feature-complete for such "independent session". I'm not disagreeing, but I'm not clear what you mean. Do you mean that GDB has a feature to allow for indepent sessions? > If there is a problem implementing it to Eclipse you can just create > a "tee"-like intermediate server: >=20 > Eclipse <-MI-> new-server <-MI-> gdb > | > console <-MI-or-CLI-+ > | > console <-MI-or-CLI-/ That is interesting. However, command-history, using arrow-up/down, is not an actual CLI command, so I wouldn't be able to reproduce that feature in the Eclipse console. > the point is every command sent by new-server -MI-> gdb should finish > immediately due to async/non-stop so any command from=20 > "console" can be sent by > new-server -MI-> gdb without any delay. >=20 > [ You should have more experience with async/non-stop/MI than=20 > me, though. ] We don't always use aync/non-stop in Eclipse. It is up to the user to decide. But that is not a problem because the eclipse GDB console, should not accept commands when GDB is busy (just like GDB's shell does not accept commands). > > Although, it would probably make the frontend out-of-sync, >=20 > This happens even with current Eclipse GDB Console, for=20 > example by modifying > a variable displayed in the Variables window. The changes done in Eclipse are pushed to GDB. However, it is the reverse that causes a problem. If the user modifies a variable in the console, there is no event to tell the frontend that something changed and should be updated in the variables view. What we do in eclipse, is that we parse all the commands sent to the console, and we try to figure out if such a command will require an update in the eclipse views. If the console was outside eclipse (like the telnet session, I'm mentioning), eclipse may not be able to catch the commands from that telnet to be able to parse them, and would then fall out-of-sync with GDB. > > 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'. >=20 > TBH isn't a VNC session to the full Eclipse GUI more suitable? Very true. A telnet session is just so easy to use, with nothing to setup. Like I said, I saw it in another debugger, which is why I was asking the question. But maybe the feature does not add much... Marc