From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20541 invoked by alias); 25 Jul 2012 19:27:25 -0000 Received: (qmail 20527 invoked by uid 22791); 25 Jul 2012 19:27:24 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Jul 2012 19:27:10 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q6PJR5oW028510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Jul 2012 15:27:05 -0400 Received: from host2.jankratochvil.net (ovpn-116-33.ams2.redhat.com [10.36.116.33]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q6PJQxOj001565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 25 Jul 2012 15:27:02 -0400 Date: Wed, 25 Jul 2012 19:27:00 -0000 From: Jan Kratochvil To: Marc Khouzam Cc: "'Abid, Hafiz'" , "'gdb-patches@sourceware.org'" Subject: Re: [patch] MI telnet service Message-ID: <20120725192653.GA24148@host2.jankratochvil.net> References: <20120725130222.GA4538@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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/msg00576.txt.bz2 On Wed, 25 Jul 2012 16:12:14 +0200, Marc Khouzam wrote: > The final goal is to allow the eclipse user to interact with > GDB using the same command-line features as the standard > GDB CLI, If it should be used somehow more regularly the TCP port needs to be reconsidered. It is already problem with gdbserver fortunately now solved by the stdio communication option. Otherwise there is problem with security on multi-user systems, also unique port allocation (why I introduced --once to gdbserver) etc. > In detail, the features Eclipse needs are: The current problem of GDB is that its CLI is not built on top of MI (*). Coding anything new is needlessly complicated needlessly combining all the modes of operation together. And instead of fixing that you go the exactly opposite direction extending use of this CLI-and-MI mixed interface even more. (*) MI as some RPC protocol, maybe some different and already established RPC protocol like D-Bus/CORBA/etc. would be better, there was a reply here MI clients are fine with MI: http://sourceware.org/ml/gdb-patches/2011-08/msg00586.html Such change from MI I find orthogonal to the changes discussed below. There were some considerations to write thin CLI client on top of MI (or even something new) just to make the internal handling of CLI vs. MI more sane. Investment into another extension on top of the current code which does not even provide readline functionality I do not find the right direction. I do not think we need to keep the behavior exactly the same, minor differences making the interface more systematic could be allowed. > - Command-history: This could be managed in Eclipse, but would > require more work to achieve the same flexibility and richness > that GDB provides. Normal readline using ~/.gdb_history should work instead. Omitting now about custom 'set history filename' etc. > - 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. There are some Java GNU readline-like packages. Personally I would be more interested in simple C/C++ thin client using GNU readline on top of the MI (or other) interface. > - Command-completion: This could be achieved using GDB's 'complete' > command. The look & feel of this feature would probably not be > exactly like in GDB which may be an annoyance to the user. And > respecting GDB preferences (if there are some that affect completion) > will require some extra handling. The 'complete' command seems right for it. > - 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. There could be additional flag sent in the result record (if MI is used). > - 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). Yes... > - Queries: Because Eclipse uses MI, GDB handles queries differently > and such queries are being automatically defaulted instead of > being presented to the user. It could default to "no" returning the question as ^error result record requesting some flag "yes" during next command execution. > 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. Do you find the proposal above worth investigation? I find the missing readline and target-async requirement complication enough of the proposed telnet solution that the CLI-on-top-of-MI solution working initially only for 90% of commands could be equally good enough. Commands the CLI-on-top-of-MI interface can send as: -interpreter-exec console "FOO" There is a question whether to translate known commands into proper existing MI commands or not. If one would want to replace MI that part would get dropped but replacing MI I find too farsighted now that maybe some extension of '-interpreter-exec console' would be more easy now. > 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. Sorry but 'screen' (or 'vnc' for Eclip=se) serves this purpose better. Thanks, Jan