From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52020 invoked by alias); 19 Jan 2017 15:47:27 -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 51941 invoked by uid 89); 19 Jan 2017 15:47:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=HX-PHP-Originating-Script:rcube.php, accurately, H*u:1.2.3, Hx-languages-length:2299 X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 19 Jan 2017 15:47:24 +0000 Received: by simark.ca (Postfix, from userid 33) id 995111E851; Thu, 19 Jan 2017 10:47:21 -0500 (EST) To: Bob Rossi Subject: Re: GDB/MI questions X-PHP-Originating-Script: 33:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 19 Jan 2017 15:47:00 -0000 From: Simon Marchi Cc: Marc Khouzam , gdb@sourceware.org In-Reply-To: <20170119151120.GB6289@xubuntu.brasko.net> References: <20170119031445.GA24616@xubuntu.brasko.net> <20170119151120.GB6289@xubuntu.brasko.net> Message-ID: X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.2.3 X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg00036.txt.bz2 On 2017-01-19 10:11, Bob Rossi wrote: > 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. > > Thanks, > Bob Rossi From experience (I'd like to be proven wrong), it will be very difficult to accurately re-create the gdb console "experience" when using MI. The commands that should or should not repeat is just one example. Consider history, tab completion, readline bindings (e.g. ctrl-R), pagination, etc. How does that work with the MI version of cgdb? If I understand correctly how annotations work, when the user types, they are interacting directly with gdb. So when they press tab to get a completion, it's handled by gdb. With MI, the user interacts with the front-end, which in turns talk to gdb. So the front-end would have to re-implement all those features. This is why gdb has this "new-ui" command that Pedro mentioned. Instead of trying to emulate a gdb console, the front-end can start GDB in standard console mode (redirecting its i/o to an embedded terminal emulator) and open a channel on the side with new-ui for MI commands. This way, when using the console, the user interacts directly with gdb, and gets the real console experience. From what I know, cgdb in entirely controlled by command line, but displays some additional info along with the source code. For example, an arrow at the execution point, and red line numbers where there are breakpoints. If you implemented it using the new-ui scheme, cgdb would just have to listen to specific events, like *stopped or =breakpoint-created to update its UI. Actually, even if you implement the console using "-interpreter-exec-console", you'll probably have to listen to those events, unless you want to parse an interpret the gdb commands the user types (which doesn't sound like a good idea). And since your UI is "read-only" (the user doesn't do run control from the UI), I think you wouldn't even need to send any MI command... In the end it's probably much easier (although there are some pitfalls to be aware of), since you offload all the user input management to gdb. Simon