> ________________________________________ > From: Pedro Alves [palves@redhat.com] > Sent: March 21, 2016 2:51 PM > To: Marc Khouzam; gdb-patches@sourceware.org > Subject: Re: [PATCH v2 00/25] Towards great frontend GDB consoles > > 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? Yes, I guess I'm one of the rare people that use interpreter-exe mi :) So, making this work is not urgent at all. But I am a little worried that if the user does issue such a command, the eclipse session stops working (as it misses the MI events). Would it be hard to disable the problematic command when 'new-ui' has been used? > > 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 From gdb-patches-return-130443-listarch-gdb-patches=sources.redhat.com@sourceware.org Mon Mar 21 19:12:38 2016 Return-Path: Delivered-To: listarch-gdb-patches@sources.redhat.com Received: (qmail 74829 invoked by alias); 21 Mar 2016 19:12:37 -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 Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 73835 invoked by uid 89); 21 Mar 2016 19:12:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 testsºYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1373, urgent 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 19:12:36 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 16B978E386; Mon, 21 Mar 2016 19:12:35 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2LJCXYm025706; Mon, 21 Mar 2016 15:12:34 -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> <56F042BF.7000700@redhat.com> From: Pedro Alves Message-ID: <56F047A1.2050509@redhat.com> Date: Mon, 21 Mar 2016 19:12: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/msg00429.txt.bz2 Content-length: 1356 On 03/21/2016 07:06 PM, Marc Khouzam wrote: >> From: Pedro Alves [palves@redhat.com] >>> 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? > > Yes, I guess I'm one of the rare people that use interpreter-exe mi :) :-) > So, making this work is not urgent at all. But I am a little worried that > if the user does issue such a command, the eclipse session stops > working (as it misses the MI events). Indeed. > Would it be hard to disable > the problematic command when 'new-ui' has been used? Hmm, probably not. I don't know yet whether it'd be hard to fix properly, but I'll take a look first before taking that route. Thanks, Pedro Alves