From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21852 invoked by alias); 19 Jan 2017 16:17:06 -0000 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 Received: (qmail 21841 invoked by uid 89); 19 Jan 2017 16:17:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=emulator, Vrany, vrany, H*f:sk:1484840 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 19 Jan 2017 16:17:04 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 797AA61BA8; Thu, 19 Jan 2017 16:17:04 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v0JGH2kK008265; Thu, 19 Jan 2017 11:17:03 -0500 Subject: Re: GDB/MI questions To: Jan Vrany , gdb@sourceware.org References: <20170119031445.GA24616@xubuntu.brasko.net> <20170119151120.GB6289@xubuntu.brasko.net> <1484840408.10710.1.camel@fit.cvut.cz> From: Pedro Alves Message-ID: <27ac7a10-40d6-d636-995c-7153cac4fe3d@redhat.com> Date: Thu, 19 Jan 2017 16:17:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1484840408.10710.1.camel@fit.cvut.cz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-01/txt/msg00039.txt.bz2 On 01/19/2017 03:40 PM, Jan Vrany wrote: > On Thu, 2017-01-19 at 15:24 +0000, Marc Khouzam wrote: >>> On Thu, Jan 19, 2017 at 02:30:58PM +0000, Marc Khouzam wrote: >>>>> Second, from the CLI if you run the command "next", then if you >>>>> hit >>>>> the enter key, GDB will run the "next" command again. >>>>> However, in GDB/MI if you run -interpreter-exec console "next", >>>>> and then >>>>> follow that with the Enter key, GDB does nothing. >>>>> Is there a way to run the last command? >>> >>> ... >>> >>>> But if you really want that for some reason, you can just keep >>>> track >>>> of the last command you sent in MI, and then when getting an lone >>>> Enter, you could send it again. But then you don't have the >>>> smarts >>>> of GDB to know which commands should repeat and which should not. >>>> I don't think this is a very good idea. >>> >>> I'm just trying to provide the same functionality I did when I was >>> using >>> annotations. This was one of the noted differences. >>> >>> Since the MI differs in this area, I've done as you suggested and >>> that works well. I guess I'll see if there are any downsides here. >> >> For the record, I'll add my voice to Pedro's suggestion to try out >> the 'new-ui' command and have a separate MI channel from your CLI. >> That is such a better user experience. >> And it shouldn't be very hard to implement in your frontend since >> you were previously handling a GDB CLI anyway. >> >> FYI, Eclipse launches GDB in CLI mode (probably like you did before) >> and let's the user interact with that CLI, while it sends MI commands >> on the >> dedicated PTY for the MI channel. >> >> Here is the parameters eclipse uses to launch such a GDB: >> >> gdb.7.12 --nx -q -ex "new-ui mi " -ex "set pagination off" >> -ex show version > > Would it work the other way round? I mean starting in MI mode and then > do something like -new-ui console /dev/some/pty ? > > This looks more "natural" to me. That was the original plan for Eclipse, but doing it the other way around turned out to be much simpler. The command works and you do get a console on /dev/some/pty, but readline won't be active on that console, so it's not the same thing. Also, ctrl-c's in that "secondary" UI likely don't reach gdb automatically. Likely we'd need some thin signal forwarding gdb agent running on that terminal, plus some other bits of coordination ("gdb is gone", SIGWINCH/"screen size changed", etc.) Something similar to emacsclient. If you start gdb in console mode in the terminal widget, then it all Just Works. GDB has no idea it's running inside a GUI at all. It's just another terminal emulator, so the experience is 100% like that of on "the normal command line". Thanks, Pedro Alves