This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v2 00/25] Towards great frontend GDB consoles
- From: Pedro Alves <palves at redhat dot com>
- To: Marc Khouzam <marc dot khouzam at ericsson dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Mon, 21 Mar 2016 18:51:43 +0000
- Subject: Re: [PATCH v2 00/25] Towards great frontend GDB consoles
- Authentication-results: sourceware.org; auth=none
- References: <1458573675-15478-1-git-send-email-palves at redhat dot com> <E59706EF8DB1D147B15BECA3322E4BDC22A06EF9 at eusaamb103 dot ericsson dot se>
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