From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28100 invoked by alias); 26 Jul 2012 00:02:23 -0000 Received: (qmail 28092 invoked by uid 22791); 26 Jul 2012 00:02:22 -0000 X-SWARE-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from elasmtp-mealy.atl.sa.earthlink.net (HELO elasmtp-mealy.atl.sa.earthlink.net) (209.86.89.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 26 Jul 2012 00:02:09 +0000 Received: from [68.96.200.16] (helo=macbook2.local) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SuBWq-0007R1-CH for gdb-patches@sourceware.org; Wed, 25 Jul 2012 20:02:08 -0400 Message-ID: <501088FF.8050703@earthlink.net> Date: Thu, 26 Jul 2012 00:02:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: [patch] MI telnet service References: <20120725130222.GA4538@host2.jankratochvil.net> <20120725192653.GA24148@host2.jankratochvil.net> In-Reply-To: <20120725192653.GA24148@host2.jankratochvil.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da94063aab25811cfa007dbd2b130b4b10849350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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/msg00599.txt.bz2 On 7/25/12 12:26 PM, Jan Kratochvil wrote: > 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. Essentially what this change is doing is making GDB itself a little more server-like. It's not an accident that interpreters and ui-files are both objects; it's been a little surprising to me that nobody has yet added the multiple-port capability to take advantage of that. >> In detail, the features Eclipse needs are: > The current problem of GDB is that its CLI is not built on top of MI (*). Huh, I don't recall ever hearing that diagnosis before. It seems like it would be incredibly hard to migrate the CLI to be an MI veneer; not only is there interactive CLI behavior that MI has never had to worry about (because it's, well, a machine interface), but MI has generally limited itself to features that were known to be of use to a frontend. > 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. The patch is kind of small though; it's mostly enabling latent capabilities, and not trying to rewrite any existing subsystems. The alternatives you suggest seem rather complicated by comparison. > >> - 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. Maybe nobody else thinks this, but adding an additional program into the Eclipse/GDB combination seems like a far more complicated approach, and has its own reliability issues, such as when the thin client crashes or hangs. >> 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. > Not so much if it's a second person that is, say, running a diagnostic script, and doesn't have any use for a mirror image of all the windows. But to pull back and take a little broader view, in a system of software components, I think GDB has a useful role as a server that can have multiple frontends, telnet-like sessions, scripted drivers, and so forth. Perhaps we should decide on whether the server concept is plausible (maybe I'm the only one who thinks that way) or to be avoided, and then go from there. Stan stan@codesourcery.com