This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v2] Restore terminal state in mi_thread_exit (PR gdb/17627)
- From: Pedro Alves <palves at redhat dot com>
- To: Simon Marchi <simon dot marchi at ericsson dot com>, gdb-patches at sourceware dot org
- Date: Thu, 04 Dec 2014 15:35:01 +0000
- Subject: Re: [PATCH v2] Restore terminal state in mi_thread_exit (PR gdb/17627)
- Authentication-results: sourceware.org; auth=none
- References: <1417558223-27328-1-git-send-email-simon dot marchi at ericsson dot com>
On 12/02/2014 10:10 PM, Simon Marchi wrote:
> When a thread exits, the terminal is left in mode "terminal_is_ours"
> while the target executes. This patch fixes that.
Right. The reason we can then type stuff is that the input fd is left
registered in the event loop. target_terminal_inferior is what
removes it.
>
> From my understanding, a function calling target_terminal_ours expects
> that the terminal could be in any state at the moment it is called.
Right. The target_terminal_* functions are idempotent.
> Therefore, it should be its reponsibility to put back the terminal in
> whatever state it was before being called.
That doesn't follow though. We have a ton of places that call
target_terminal_our that don't need to put back the terminal in
whatever state is was before. The reason is that usually we'll
be printing after the inferior stopped for some event. If we end
up re-resuming it, we'll call target_terminal_inferior then.
But in the thread exit case, there's nothing to be re-resumed,
so we need to care about it "manually". If you take a backtrace
at the point the thread exit event is printed, we should be
still deep within the target backend code.
Please update the commit log to clarify this.
> extern int target_supports_terminal_ours (void);
>
> +/* Make a cleanup that restores the state of the terminal to the current
> + value. */
Should be "to the current state", I think.
Otherwise OK.
Thanks,
Pedro Alves