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

[Marc Khouzam <marc dot khouzam at ericsson dot com>]

> ________________________________________
> 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