Re: GDB/MI and ">" prompts (was: Interactive behavior of GDB run from Emacs on Windows)

[Joel Brobecker <brobecker at adacore dot com>]

> With this knowhow in hand, my next question is about GDB/MI behavior
> when it is connected to a tty device.  Typing
> 
>   -interpreter-exec console "commands"
> 
> from the console for some reason disables the ">" prompts for the
> breakpoint commands.  If stdin is NOT a tty, those prompts _are_
> output.  Why the difference?

I don't know if it is a feature or a bug. I would lean towards a bug.
GDB treats all prompts the same, and asks the current interpreter
whether to display the prompt or not. See gdb_readline_wrapper,
which calls display_gdb_prompt, which does:

  /* Each interpreter has its own rules on displaying the command
     prompt.  */
  if (!current_interp_display_prompt_p ())
    return;

Although we are executing the command using the console interpreter,
the current interpreter remains the GDB/MI interpreter:

    (top-gdb) p *current_interpreter
    $11 = {name = 0x19b8ce0 "mi", next = 0x19b9ec0, data = 0x1a32390,
           inited = 1, procs = 0x94d480, quiet_p = 0}

And thus, current_interp_display_prompt_p returns false.

Just to see what would happen if the GDB/MI interpreter was to
display prompts, I tweaked mi_interpreter_prompt_p to always
return 1, and here is what I get:

    -interpreter-exec console "commands 1"
    ~"Type commands for breakpoint(s) 1, one per line.\nEnd with a line saying just \"end\".\n"
    ~">"
    print 1
    ~">"
    print 2
    ~">"
    end

The ~ lines are lines that would be printed verbatim on the debugger
console, so I believe the user experience would be similar to what
we get in non-MI mode.

But of course, things are not as simple as this, since I do not think
we want the GDB/MI to always print the prompt.  Although, I didn't
see how always returning 1 made a difference elsewhere, in particular
with the main GDB prompt. So perhaps that could be a solution, I just
don't know enough about this to be sure.

The other thing that occured to me was that, perhaps, we should instead
be switching the interpreter while executing the console command,
but I doubt that would be correct.

-- 
Joel