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

Pedro Alves
2016-05-06T12:58:13Z

On 03/21/2016 06:51 PM, Pedro Alves wrote:
>
>> > 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?

For the record, this was indeed related to MI globals. Specifically,
"raw_stdout". Fixed by making it be per-MI instead:

https://sourceware.org/ml/gdb-patches/2016-05/msg00130.html

>> >
>> > 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".

This was related to an issue with how gdb starts inferiors. It
vforks, then uses ptrace (PTRACE_ME), and then execs. Between
the vfork and the exec, the child was running with the MI channel
as current UI, and because it's a vfork, that messed up the
parent gdb's structures. Fixed here, with a testcase that
ensures that "set inferior-tty" use cases are correctly handled:

https://sourceware.org/ml/gdb-patches/2016-05/msg00128.html

Thanks,
Pedro Alves