Interactive behavior of GDB run from Emacs on Windows

Interactive behavior of GDB run from Emacs on Windows

[Eli Zaretskii]

There's an annoying difference between GDB behavior when launched by
Emacs GUD on Windows and on Posix platforms.  AFAIU, the difference is
explained by the fact that on Posix platforms the communications
between Emacs and GDB are done via a pty, whereas on Windows Emacs
uses pipes.  Therefore, on Unix GDB behaves as if its standard handles
were connected to a terminal, while on Windows it doesn't.

This causes some prompts, like the one GDB displays after "commands"
etc., not to show on Windows, and also rears its ugly head in other
situations.

What would be the best way to solve this annoyance?  One possibility I
thought of would be to have a "set something" option which Emacs would
cram down the pipe early on, that will force GDB to behave as if it
were talking to a terminal (we already have a similar hack for
Insight).  Would that be acceptable, and is it easily and cleanly
doable?  (I don't know enough about the ser-*.c stuff to decide
whether there could be any pitfalls along this route.)

TIA

Re: Interactive behavior of GDB run from Emacs on Windows

[Joel Brobecker]

On Thu, Apr 19, 2012 at 06:45:28PM +0300, Eli Zaretskii wrote:
> There's an annoying difference between GDB behavior when launched by
> Emacs GUD on Windows and on Posix platforms.  AFAIU, the difference is
> explained by the fact that on Posix platforms the communications
> between Emacs and GDB are done via a pty, whereas on Windows Emacs
> uses pipes.  Therefore, on Unix GDB behaves as if its standard handles
> were connected to a terminal, while on Windows it doesn't.

Try the following, I think it might help:

    (gdb) set interactive-mode on

-- 
Joel

Re: Interactive behavior of GDB run from Emacs on Windows

[Eli Zaretskii]

> Date: Thu, 19 Apr 2012 08:48:53 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb@sourceware.org
> 
> On Thu, Apr 19, 2012 at 06:45:28PM +0300, Eli Zaretskii wrote:
> > There's an annoying difference between GDB behavior when launched by
> > Emacs GUD on Windows and on Posix platforms.  AFAIU, the difference is
> > explained by the fact that on Posix platforms the communications
> > between Emacs and GDB are done via a pty, whereas on Windows Emacs
> > uses pipes.  Therefore, on Unix GDB behaves as if its standard handles
> > were connected to a terminal, while on Windows it doesn't.
> 
> Try the following, I think it might help:
> 
>     (gdb) set interactive-mode on

Thanks, it does.

Now I need to fix the manual, so the next time I will find this
stuff...

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

[Eli Zaretskii]

> Date: Thu, 19 Apr 2012 19:10:18 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: gdb@sourceware.org
> 
> > Try the following, I think it might help:
> > 
> >     (gdb) set interactive-mode on
> 
> Thanks, it does.

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?

Were this makes difference is in Emacs, which now uses MI to interact
with GDB, but it also supports the command-line interface, by taking
the commands typed by the user and wrapping them in "-interpreter-exec".
But the lack of the ">" prompts makes the user experience worse, so
I'm asking why is GDB behaving like that.

TIA

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

[Joel Brobecker]

> 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

Re: GDB/MI and ">" prompts

[Eli Zaretskii]

> Date: Thu, 19 Apr 2012 11:53:29 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb@sourceware.org
> 
> > 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,

Do we really use readline when MI is the interpreter?

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

Right.  But you don't need to hack the code to see this in action,
just "set interactive-mode off" and you will see it.

The crux of my question was why non-interactive mode does display a
prompt while the interactive one doesn't.

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

Does GDB/MI have a prompt?  The ">" thing is coming from the CLI, not
from MI.  Or did you mean other prompts in other situations (and if
so, which ones)?

> The other thing that occured to me was that, perhaps, we should instead
> be switching the interpreter while executing the console command,

How would that help?