From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30665 invoked by alias); 26 Jul 2012 11:51:58 -0000 Received: (qmail 30656 invoked by uid 22791); 26 Jul 2012 11:51:57 -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; Thu, 26 Jul 2012 11:51:38 +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 q6QBpbSL001342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jul 2012 07:51:37 -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 q6QBpVer027240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 26 Jul 2012 07:51:34 -0400 Date: Thu, 26 Jul 2012 11:51:00 -0000 From: Jan Kratochvil To: Stan Shebs Cc: gdb-patches@sourceware.org Subject: Re: [patch] MI telnet service Message-ID: <20120726115125.GA29134@host2.jankratochvil.net> References: <20120725130222.GA4538@host2.jankratochvil.net> <20120725192653.GA24148@host2.jankratochvil.net> <501088FF.8050703@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <501088FF.8050703@earthlink.net> 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/msg00609.txt.bz2 On Thu, 26 Jul 2012 02:02:07 +0200, Stan Shebs wrote: > Essentially what this change is doing is making GDB itself a little > more server-like. I find this design fine, I am not against it. But from the implementation point of view it mixes together with the long-term pain of mixed CLI and MI processing. The goal is to produced only raw data (like MI does) by current GDB code and to have a completely different code formatting the MI data as CLI (the way Eclipse formats the MI data as GUI) ------------------------------------------------------------------------------ If it is not clear why the CLI and MI processing mix is a pain I can illustrate on (but there are many such cases in GDB) http://sourceware.org/ml/gdb-patches/2011-09/msg00558.html as the code handles 7 modes of "set print entry-values" setting (it has to). But additionally to it the same code has to handle both proper readable output in CLI mode and proper MI output where the MI output is done in two passes. In reality one has to put all the combinations into the testsuite as otherwise a minor edit will break some of the 21 modes each lines of code runs in. ------------------------------------------------------------------------------ Formally the patterns of separating of the code I have Googled out as: http://en.wikipedia.org/wiki/Separation_of_concerns specifically here proposing roughly current GDB to be 'model', its MI to be 'adapter' and new-CLI-on-top-of-MI client + Eclipse to be 'view': http://en.wikipedia.org/wiki/Model-view-adapter This way the interface of GDB will be only MI which can be easily multiplexed into multiple views. One of the view to be still Eclipse and other views to be each CLI (also easily featuring GNU readline). > 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. If there is some way how to implement multiple GNU readlines it may be reconsidered but I find CLI without readline to be unusable. > 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; See above. > not only is there interactive CLI behavior That's the problem, mixing UI with GDB logic. Also because usually different types of developers maintain each kind of code, which is unfortunately currently mixed together. > 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. Yes, MI would need to be extended many times so that the CLI-on-top-of-MI interface no longer has to use the '-interpreter-exec console ...' hack. > 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. (1) I do not see that Eclipse should run another program, it is up to Eclipse which way it would be implemented there. IIUC Eclipse would use GNU readline classes, with no new process involved. (2) New program (*) is better, when it means reducing the codebase of the original program (=removing CLI from current GDB codebase; in the future). (*) I do not say CLI-on-top-of-MI client needs to really run as a separate UNIX process, but it should be possible to run it that way. In reality it may be something like just linkage with libgdb.a. > 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. I agree. Just GDB should not directly interface by CLI, this has been already a pain and it is no longer well extensible. This also currently means that any '--More--' prompt will stop all the other connected clients, so a forgotten '--More--' prompt in the lab will prevent the designer to connect to the same GDB from home anyway. I will hopefully get to coding some very basic CLI-on-top-of-MI client to see how practically usable it is. Thanks, Jan