Re: [PATCH] Don't send queries to the MI interpreter

[Pedro Alves <palves at redhat dot com>]

On 02/10/2017 05:44 PM, Pedro Alves wrote:

> OK, I found the branch.  Pushed here now:
> 
>   https://github.com/palves/gdb/commits/palves/console-pagination

And re-reading the branch again, I noticed this hunk:

@@ -1255,7 +1258,9 @@ defaulted_query (const char *ctlstr, const char defchar, va_list args)
      way, important error messages don't get lost when talking to GDB
      over a pipe.  */
   if (current_ui->instream != current_ui->stdin_stream
-      || !input_interactive_p (current_ui))
+      || !input_interactive_p (current_ui)
+      /* We can't handle nested queries.  */
+      || current_ui != main_ui)
     {
       old_chain = make_cleanup_restore_target_terminal ();
 
@@ -2045,36 +2050,48 @@ begin_line (void)
     }
 }

This is similar to your patch, but it handles something your
version doesn't, I think.  That is the case of handling the secondary
channel being a CLI interpreter, not an MI one, and that UI
having been started on a terminal.

Until we put each UI/interpreter on its own thread, with its
own event loop, we can't handle multiple UIs querying
simultaneously.  Picture this situation:

Do this first on UI #1:

 (gdb) handle SIGINT
 SIGINT is used by the debugger.
 Are you sure you want to change it? (y or n) 

And then this on UI #2:

 (gdb) handle SIGTRAP
 SIGTRAP is used by the debugger.
 Are you sure you want to change it? (y or n) 

Now answer "yes" on UI #1.  What happens?

GDB incorrectly changes SIGTRAP, not SIGINT, and
probably gets the UIs messed up. 

Why?

Because we'd have this in pseudo-backtrace:

#0 gdb_readline_wrapper
#1 defaulted_query                 // for UI #2
#2 handle_command
#3 execute_command ("handle SIGTRAP" ....
#4 stdin_event_handler             // input on UI #2
#5 gdb_do_one_event
#7 gdb_readline_wrapper
#8 defaulted_query                 // for UI #1
#9 handle_command
#10 execute_command ("handle SIGINT" ....
#11 stdin_event_handler            // input on UI #1
#12 gdb_do_one_event
#13 gdb_readline_wrapper

So answering "yes", returns the read input to the
query in frame #1...

So that hunk addresses this by only allowing queries on
the main UI, similarly to how we only enable readline
on the main UI.

So I think that to support multiple queries like that
the simplest / most natural would be to make each
UI above run on its own thread, so that each would have
its own independent stack/frames.

Thanks,
Pedro Alves