From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4847 invoked by alias); 29 Nov 2010 20:39:30 -0000 Received: (qmail 4837 invoked by uid 22791); 29 Nov 2010 20:39:28 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,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; Mon, 29 Nov 2010 20:39:20 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oATKdJak023417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 29 Nov 2010 15:39:19 -0500 Received: from host0.dyn.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id oATKdDNR013409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 29 Nov 2010 15:39:18 -0500 Received: from host0.dyn.jankratochvil.net (localhost.localdomain [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.4/8.14.4) with ESMTP id oATKdAuE018655; Mon, 29 Nov 2010 21:39:11 +0100 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.4/8.14.4/Submit) id oATKd7TX018654; Mon, 29 Nov 2010 21:39:07 +0100 Date: Mon, 29 Nov 2010 20:39:00 -0000 From: Jan Kratochvil To: Marc Khouzam Cc: "'gdb@sourceware.org'" Subject: Re: Using telnet to control a running GDB Message-ID: <20101129203906.GA18241@host0.dyn.jankratochvil.net> References: <20101129025627.GA4356@host0.dyn.jankratochvil.net> <20101129185524.GA13721@host0.dyn.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-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/msg00127.txt.bz2 On Mon, 29 Nov 2010 21:00:34 +0100, Marc Khouzam wrote: > 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? It is the same as event-driven vs. threading model. The event-driven model is for example implemented by Gnome/GLib applications. There is a mainloop waiting for events, any event is immediately processed, further actions are remembered (like GDB continuations) and execution always immediately drops back to the mainloop. With threading model each action creates new thread and such thread waits and tracks that one specific action until it completes. This two approach are equivalent, they just require different coding approach. GDB async represents the event-driven one, you request "independent sessions" representing the threading model. The threading model is more intuitive for coding but it is more resources demanding. (gdb) continue & (gdb) print 1 + 2 # this command may come from an "independent session" > 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. command-history has no place in a communication protocol. It is a user-interface local feature. You can implement readline-like feature in Eclipse console by some library like JLine as a JNI interface to arch-specific real GNU readline would be probably a complication for Eclipse distribution. > 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). The "indepent session" would not be possible without async/non-stop. > 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. That is not nice but I understand there is currently no other way. > 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. MI should rather notify changes done over MI when talking about some right way to do it. Thanks, Jan