RE: [PATCH v2 00/25] Towards great frontend GDB consoles

Marc Khouzam
2016-03-21T19:06:28Z

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 8078 bytes --]

> ________________________________________
> 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: <gdb-patches-return-130443-listarch-gdb-patches=sources.redhat.com@sourceware.org>
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: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
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 <marc.khouzam@ericsson.com>, "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
References: <1458573675-15478-1-git-send-email-palves@redhat.com> <E59706EF8DB1D147B15BECA3322E4BDC22A06EF9@eusaamb103.ericsson.se> <56F042BF.7000700@redhat.com> <E59706EF8DB1D147B15BECA3322E4BDC22A06FCB@eusaamb103.ericsson.se>
From: Pedro Alves <palves@redhat.com>
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: <E59706EF8DB1D147B15BECA3322E4BDC22A06FCB@eusaamb103.ericsson.se>
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