From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2991 invoked by alias); 21 Mar 2016 18:51:51 -0000 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 Received: (qmail 2977 invoked by uid 89); 21 Mar 2016 18:51:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=feedback!, quality 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 21 Mar 2016 18:51:45 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 70DD91F57C; Mon, 21 Mar 2016 18:51:44 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2LIph6P023801; Mon, 21 Mar 2016 14:51:43 -0400 Subject: Re: [PATCH v2 00/25] Towards great frontend GDB consoles To: Marc Khouzam , "gdb-patches@sourceware.org" References: <1458573675-15478-1-git-send-email-palves@redhat.com> From: Pedro Alves Message-ID: <56F042BF.7000700@redhat.com> Date: Mon, 21 Mar 2016 18:51:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-03/txt/msg00427.txt.bz2 On 03/21/2016 06:34 PM, Marc Khouzam wrote: >> From: Pedro Alves [palves@redhat.com] >> Sent: March 21, 2016 11:20 AM >> To: gdb-patches@sourceware.org >> Cc: Marc Khouzam >> Subject: [PATCH v2 00/25] Towards great frontend GDB consoles >> >> Here's an update of the series I first posted here: >> https://sourceware.org/ml/gdb-patches/2016-02/msg00067.html >> >> New in v2: >> >> - The "Command line input handling TLC" patch [1] has since been split >> into a series of its own [2], and pushed in. >> >> [1] https://sourceware.org/ml/gdb-patches/2016-02/msg00070.html >> [2] https://sourceware.org/ml/gdb-patches/2016-02/msg00557.html >> >> - Currently, if GDB's (main) stdin closes, GDB exits. That logic >> carried over to secondary UIs as well, by mistake, so v1, if a >> secondary UI's terminal was closed, GDB would just exit as well... >> In v2, that's now detected, and GDB just discards the UI. >> >> - I noticed that if you typed something in a secondary UI, and then >> Ctrl-C'd the main UI, GDB would internal error. The problem was >> that nothing was making use async signal handlers (in this case, >> async_request_quit) always run on the main UI. >> >> - Added a convenience "info uis" command to list UIs. >> >> - Some cleanups here and there >> >> Force-pushed to users/palves/console at sourceware.org. > > From the previous testing I did, and from the demo I gave, > your previous patches were already of very good quality. > Thank you for those. > Glad to hear that! Sounds like we're not that far off then. > Right now, there are only three issues that I can report. > They are present in v2. > > 1- The new-ui command should not be a repeating command Indeed. > 2- Using 'interpreter-exec mi" in the CLI console confuses GDB > To reproduce from a shell > - start GDB in CLI mode > - give a "new-ui mi" command to start an MI channel > - start running the inferior => *stopped/*running events are on the MI channel > - in the CLI send command interpreter-exec mi "" > - step or resume > => *stopped/*running events are now on the CLI channel and not the MI one I can reproduce this. This may be related to the fact that MI's code still has a bunch of globals that I hadn't made per-UI, thinking that that would be sufficient for the use case at hand. While annoying, I wouldn't expect a regular user / script to be issuing MI commands, right? > > 3- Issues when using "set inferior-tty" > To reproduce from a shell > - start GDB in CLI mode > - give a "new-ui mi" command to start an MI channel > - use "set inferior-tty" to another tty (like eclipse does) > - in the MI channel, use -exec-run > => the shell where GDB CLI is running no longer responds to input Interesting. I can reproduce this as well. I wonder if it's related to PR gdb/18077 (-exec-run results in synchronous execution), but then again, it doesn't reproduce without "set inferior-tty". > > Feel free to ask for any clarifications. > > I'll be doing some more thorough testing using this feature with Eclipse, as the integration > is almost done. I'll communicate any other issues I find. > > Thanks again! Thanks for the feedback! -- Pedro Alves