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

[Pedro Alves]

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