[Bug gdb/20494] User input stops being echoed in CLI

["palves at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=20494

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palves at redhat dot com

--- Comment #2 from Pedro Alves <palves at redhat dot com> ---
Took me all morning to figure out what's going on, but I think I'm seeing the
problem.

Setting a break on _rl_echoing_p helped.  I also noticed that this only
triggers if you do "start" in MI first.  If you do "start" in the console
first, and then restart the inferior in the MI UI, the problem doesn't trigger.
 Which suggested something along the lines of some wrong state getting cached
somewhere.

Here's the problem:

- gdb_has_a_terminal computes the result lazily, on first call.

  that saves gdb's main terminal state (the console UI's):

          our_terminal_info.ttystate = serial_get_tty_state (stdin_serial);

  This is the state that "target_terminal_ours" restores.

- the gdb_has_a_terminal function is first ever called from within 
  target_terminal_init, within "start".

And the difference between first issuing "start" in MI vs issuing it in the
console is in whether readline has deprepped the terminal (rl_deprep_terminal)
when the gdb_has_a_terminal function is reached:

- console UI: readline has deprepped the terminal.

- MI UI: readline has not deprepped the terminal.

In the MI case, we end up storing readline's prepped state in 
our_terminal_info.ttystate, which includes echo disabled...

-- 
You are receiving this mail because:
You are on the CC list for the bug.