From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15081 invoked by alias); 25 Jul 2012 14:12:41 -0000 Received: (qmail 15060 invoked by uid 22791); 25 Jul 2012 14:12:39 -0000 X-SWARE-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from imr4.ericy.com (HELO imr4.ericy.com) (198.24.6.9) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Jul 2012 14:12:26 +0000 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q6PECK3a017832; Wed, 25 Jul 2012 09:12:21 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.135]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 25 Jul 2012 10:12:15 -0400 From: Marc Khouzam To: "'Jan Kratochvil'" , "'Abid, Hafiz'" CC: "'gdb-patches@sourceware.org'" Date: Wed, 25 Jul 2012 14:12:00 -0000 Subject: RE: [patch] MI telnet service Message-ID: References: <20120725130222.GA4538@host2.jankratochvil.net> In-Reply-To: <20120725130222.GA4538@host2.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-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-07/txt/msg00525.txt.bz2 > -----Original Message----- > From: gdb-patches-owner@sourceware.org=20 > [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Jan Kratochvil > Sent: Wednesday, July 25, 2012 9:02 AM > To: Abid, Hafiz > Cc: gdb-patches@sourceware.org > Subject: Re: [patch] MI telnet service > Have you talked to Eclipse maintainers why they do not=20 > provide separate > console? In fact they do, I find it more fits there. If=20 > communication with > Eclipse developers has failed GDB can implement it, but I=20 > find it more as Eclipse workaround. I understand your point-of-view. There are advantages to having this feature in GDB instead of Eclipse though. The final goal is to allow the eclipse user to interact with GDB using the same command-line features as the standard GDB CLI, and to keep Eclipse up-to-date with respect to the changes made through this console. The latter point is being addressed separately by adding more MI events. This telnet patch attempts to make it easier for Eclipse to give a full CLI to the user directly in Eclipse.=20 Conceptually one can argue that "interacting directly with GDB=20 should be handled by GDB itself" and not have go through another layer pretending to be GDB. Furthermore, something feels wrong and limiting about providing a CLI look & feel while going through the MI channel used by Eclipse. In detail, the features Eclipse needs are: - Command-history: This could be managed in Eclipse, but would require more work to achieve the same flexibility and richness that GDB provides. - Readline features: This is more complicated. We could implement the same readline features directly in Eclipse (there is probably a package we could use to get this working) but re-using GDB's existing feature seems a simpler path to take. Also, and I'm not sure of this, it may be even more effort to get this to work for Windows also, while GDB provides all this already. - Command-completion: This could be achieved using GDB's 'complete' command. The look & feel of this feature would probably not be=20 exactly like in GDB which may be an annoyance to the user. And=20 respecting GDB preferences (if there are some that affect completion) will require some extra handling. - Repeat last command: I don't believe this can be done in Eclipse without GDB's help, and I don't know of a way to ask GDB if a command should be repeated or not. - Prompt: GDB does some smart handling of the prompt, which would have to be replicated in Eclipse (or at least a poor-man's version). - Queries: Because Eclipse uses MI, GDB handles queries differently and such queries are being automatically defaulted instead of being presented to the user. There are probably a couple of more that slip my mind right now. We felt that the most efficient way to get this feature was to re-use as much of GDB's features as possible, which explains why this telnet approach is being proposed. Beyond the Eclipse use-case, I personally feel that this telnet feature adds value to GDB for other situations. For example, a designer could remote connect to a running GDB that was setup in the lab, or one could continue a debug session after having gone home. Not world-changing, but valuable nonetheless IMHO. Your comments are most welcomed. Thanks Marc