[RFA/RFC] new setting against auto-answer? (because "input not from terminal")

[RFA/RFC] new setting against auto-answer? (because "input not from terminal")

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 1879 bytes --]

Hello,

I often have to investigate issues on Windows, except that I usually
don't work locally on a Windows machine.  So, usually, what I do is
ssh to a Windows machine where we have a cygwin SSH daemon running.

If you have been in that situation, and you use a MinGW debugger,
then you probably know that there are a few issues with the "terminal".
One of the issues that is causing us some trouble is the fact that
GDB automatically assumes the default answer for its y/n queries.
For instance:

    (top-gdb) start
    The program being debugged has been started already.
    Start it from the beginning? (y or n) [answered Y; input not from terminal]
    [...]

I propose a new "set/show interactive-mode (auto|on|off)" command
to allow the user to override what GDB detects. By default, GDB
still probes stdin and determines from there what mode should be
used.  But if the user knows what he's doing, he can force it in
situations where GDB's default behavior is less useful.

    (top-gdb) set interactive-mode on
    (top-gdb) start
    The program being debugged has been started already.
    Start it from the beginning? (y or n) n
    Program not restarted.

Attached is a patch that implements that. The name of the option
can be changed if we find a better one. If others are interested,
then I'll work on producing documentation and a little testcase.

2008-10-24  Joel Brobecker  <brobecker@adacore.com>

        * top.c (interactive_mode_auto, interactive_mode_on)
        (interactive_mode_off, interactive_mode_enum, interactive_mode):
        New static globals.
        (show_interactive_mode): New function.
        (input_from_terminal_p): If interactive_mode is not auto, then
        use that rather than checking the stdin settings.
        (init_main): Add "set/show interactive-mode" command.

Tested on x86-linux, no regression.

Thoughts?
-- 
Joel

[-- Attachment #2: top.c.diff --]
[-- Type: text/plain, Size: 2831 bytes --]

Index: top.c
===================================================================
RCS file: /cvs/src/src/gdb/top.c,v
retrieving revision 1.154
diff -u -p -r1.154 top.c
--- top.c	22 Sep 2008 15:24:51 -0000	1.154
+++ top.c	25 Oct 2008 00:48:15 -0000
@@ -1298,12 +1298,52 @@ quit_force (char *args, int from_tty)
   exit (exit_code);
 }
 
+/* Enum strings for "set|show interactive-mode".  */
+
+static const char interactive_mode_auto[] = "auto";
+static const char interactive_mode_on[] = "on";
+static const char interactive_mode_off[] = "off";
+static const char *interactive_mode_enum[] =
+{
+  interactive_mode_auto,
+  interactive_mode_on,
+  interactive_mode_off,
+  NULL
+};
+
+/* If OFF, the debugger will run in non-interactive mode, which means
+   that it will automatically select the default answer to all the
+   queries made to the user.  If ON, gdb will wait for the user to
+   answer all queries.  If AUTO, gdb will determine whether to run
+   in interactive mode or not depending on whether stdin is a terminal
+   or not.  */
+
+static const char *interactive_mode = interactive_mode_auto;
+
+/* Implement the "show interactive-mode" option.  */
+
+static void
+show_interactive_mode (struct ui_file *file, int from_tty,
+                       struct cmd_list_element *c,
+                       const char *value)
+{
+  if (interactive_mode == interactive_mode_auto)
+    fprintf_filtered (file, "\
+Debugger's interactive mode is %s (currently %s).\n",
+                      value, input_from_terminal_p () ? "on" : "off");
+  else
+    fprintf_filtered (file, "Debugger's interactive mode is %s.\n", value);
+}
+
 /* Returns whether GDB is running on a terminal and input is
    currently coming from that terminal.  */
 
 int
 input_from_terminal_p (void)
 {
+  if (interactive_mode != interactive_mode_auto)
+    return interactive_mode == interactive_mode_on;
+
   if (gdb_has_a_terminal () && instream == stdin)
     return 1;
 
@@ -1633,6 +1673,20 @@ Use \"on\" to enable the notification, a
 			   NULL,
 			   show_exec_done_display_p,
 			   &setlist, &showlist);
+
+  add_setshow_enum_cmd ("interactive-mode", class_support,
+                        interactive_mode_enum, &interactive_mode,
+                        _("\
+Set whether gdb should run in interactive mode or not"), _("\
+Show whether gdb runs in interactive mode"), _("\
+If on, gdb runs in interactive mode and waits for the user to answer\n\
+all its queries.  If off, gdb runs in non-interactive mode and\n\
+automatically assumes the default answer to all its queries.  If auto\n\
+(which is the default), automatically determine which mode to use based\n\
+on the standard input settings"),
+                        NULL,
+                        show_interactive_mode,
+                        &setlist, &showlist);
 }
 
 void

Re: [RFA/RFC] new setting against auto-answer? (because "input not from terminal")

[Paul Hilfinger]

 > If you have been in that situation, and you use a MinGW debugger,
 > then you probably know that there are a few issues with the "terminal".
 > One of the issues that is causing us some trouble is the fact that
 > GDB automatically assumes the default answer for its y/n queries.
 > For instance:
 > 
 >     (top-gdb) start
 >     The program being debugged has been started already.
 >     Start it from the beginning? (y or n) [answered Y; input not from terminal]
 >     [...]
 > 
 > I propose a new "set/show interactive-mode (auto|on|off)" command
 > to allow the user to override what GDB detects. By default, GDB
 > still probes stdin and determines from there what mode should be
 > used.  But if the user knows what he's doing, he can force it in
 > situations where GDB's default behavior is less useful.

If the behavior of GDB on other OS's is OK, shouldn't this be a
configuration parameter of some sort, preferably set automatically by
configure?

Paul Hilfinger

Re: [RFA/RFC] new setting against auto-answer? (because "input not from terminal")

[Joel Brobecker]

>  > I propose a new "set/show interactive-mode (auto|on|off)" command
>  > to allow the user to override what GDB detects. By default, GDB
>  > still probes stdin and determines from there what mode should be
>  > used.  But if the user knows what he's doing, he can force it in
>  > situations where GDB's default behavior is less useful.
> 
> If the behavior of GDB on other OS's is OK, shouldn't this be a
> configuration parameter of some sort, preferably set automatically by
> configure?

I don't think it would be a good idea to make it a configure parameter.
If you freeze the setting to interactive mode at configure time, then
the debugger is stuck in that mode, even when stdin is a real pipe:

        cat commands | gdb

-- 
Joel

Re: [RFA/RFC] new setting against auto-answer? (because "input not from terminal")

[Eli Zaretskii]

> Date: Fri, 24 Oct 2008 18:04:45 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> 
> If you have been in that situation, and you use a MinGW debugger,
> then you probably know that there are a few issues with the "terminal".
> One of the issues that is causing us some trouble is the fact that
> GDB automatically assumes the default answer for its y/n queries.
> For instance:
> 
>     (top-gdb) start
>     The program being debugged has been started already.
>     Start it from the beginning? (y or n) [answered Y; input not from terminal]
>     [...]
> 
> I propose a new "set/show interactive-mode (auto|on|off)" command
> to allow the user to override what GDB detects.

Isn't it better to fix the original problem?

Is the problem with isatty returning the wrong value?  If so, did you
(or can you) try the following trick?

  #define ISATTY(fd) (isatty(fd) && lseek(fd,SEEK_CUR,0) == -1)

and then use ISATTY instead of isatty?

Re: [RFA/RFC] new setting against auto-answer? (because "input not from terminal")

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel> +static const char *interactive_mode_enum[] =
Joel> +{
Joel> +  interactive_mode_auto,
Joel> +  interactive_mode_on,
Joel> +  interactive_mode_off,
Joel> +  NULL
Joel> +};

Joel> +  add_setshow_enum_cmd ("interactive-mode", class_support,

I think you could use var_auto_boolean instead of var_enum here.

Tom

Re: [RFA/RFC] new setting against auto-answer? (because "input not from terminal")

[Joel Brobecker]

> Is the problem with isatty returning the wrong value?  If so, did you
> (or can you) try the following trick?
> 
>   #define ISATTY(fd) (isatty(fd) && lseek(fd,SEEK_CUR,0) == -1)
> 
> and then use ISATTY instead of isatty?

That wouldn't work, unfortunately, because the problem is that isatty 
returns zero. In the case of ssh to cygwin sshd, it's expected, since
my understanding is that cygwin uses pipes. There is also another
context that we use to run GDB, which is GPS.  I need to double-check
with one of my collegues in Spain, but I believe that GPS creates a
console, and somehow MinGW's isatty also returns zero.

I assume that the first issue (with cygwin sshd) is fixable, since
running cygwin's GDB, the debugger detects a "terminal" and runs in
the right mode. I'll take a look at the sources and see if I can find
something.

In the second case, I don't really know. Perhaps fixing the first
case will fix this one as well.

-- 
Joel

Re: [RFA/RFC] new setting against auto-answer? (because "input not from terminal")

[Daniel Jacobowitz]

On Sat, Oct 25, 2008 at 08:45:29AM -0700, Joel Brobecker wrote:
> I assume that the first issue (with cygwin sshd) is fixable, since
> running cygwin's GDB, the debugger detects a "terminal" and runs in
> the right mode. I'll take a look at the sources and see if I can find
> something.

It is very, very hard :-(

The only way we've been able to find to deal with this is to find
Cygwin and ask it if there's a TTY; and you can't even do it by
spawning /bin/tty, since tty-ness won't pass through an intermediate
Windows process.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFA/RFC] new setting against auto-answer? (because "input not from terminal")

[Eli Zaretskii]

> Date: Sat, 25 Oct 2008 08:45:29 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb-patches@sourceware.org
> 
> > Is the problem with isatty returning the wrong value?  If so, did you
> > (or can you) try the following trick?
> > 
> >   #define ISATTY(fd) (isatty(fd) && lseek(fd,SEEK_CUR,0) == -1)
> > 
> > and then use ISATTY instead of isatty?
> 
> That wouldn't work, unfortunately, because the problem is that isatty 
> returns zero.

What does lseek return with the above arguments?

Re: [RFA/RFC] new setting against auto-answer? (because "input not from terminal")

[Joel Brobecker]

> > >   #define ISATTY(fd) (isatty(fd) && lseek(fd,SEEK_CUR,0) == -1)
> > > 
> > > and then use ISATTY instead of isatty?
> > 
> > That wouldn't work, unfortunately, because the problem is that isatty 
> > returns zero.
> 
> What does lseek return with the above arguments?

Here are some results:

   lseek (fd, 0, SEEK_CUR) -> 0
   lseek (fd, -1, SEEK_CUR) -> 0
   lseek (fd, 1, SEEK_CUR) -> 1

The results are identical regardless of whether GDB is started 
in interactive mode or in batch mode (commands fed through a pipe).

-- 
Joel

Re: [RFA/RFC] new setting against auto-answer? (because "input not from terminal")

[Joel Brobecker]

> 2008-10-24  Joel Brobecker  <brobecker@adacore.com>
> 
>         * top.c (interactive_mode_auto, interactive_mode_on)
>         (interactive_mode_off, interactive_mode_enum, interactive_mode):
>         New static globals.
>         (show_interactive_mode): New function.
>         (input_from_terminal_p): If interactive_mode is not auto, then
>         use that rather than checking the stdin settings.
>         (init_main): Add "set/show interactive-mode" command.

It didn't feel like there was a lot of interest in this feature,
so I'm not going to push it any further. Please scream if you'd
actually like to see it included in GDB - as pointed out by Tom,
I need to improve it a little bit (which I'll do for our own tree
anyways).  In the meantime, we'll keep this change local to
AdaCore's GDB.

-- 
Joel