bug#12163: 24.1; Can not input anything or showing none output when debugging c/c++ application.

[Eli Zaretskii <eliz@gnu.org>]

> From: qq510371827 <qq510371827@gmail.com>
> Date: Fri, 10 Aug 2012 18:18:44 +0800
> 
> Ok,source code is as follows:
> #include "stdio.h"
> #include "ctype.h"
> #include "string.h"
> 
> void Reverse(char* p,int n)
> {
>     if(--n > 0) Reverse(p+1,n);
>     printf("%c",*p);
>     fflush(stdout);
> }
> int main()
> {
>   //setbuf(stdin,NULL);
>   //setbuf(stdout,NULL);
>   // setvbuf(stdin,NULL,_IONBF,0);
>   // setvbuf(stdout,NULL,_IONBF,0);
>   //freopen("input.txt","r",stdin);
>     char s[255],*p,*q;
>     int i=0,n;
>     fgets(s,255,stdin);
>     s[strlen(s)-1] = ' ';
>     p = q = s;                               //  set breakpoint at this line.
>     while(*p != '\0')
>     {
>         i++;
>         p++;
>         if(isspace(*p))
>         {
>             n = i;
>             i = 0;
>             Reverse(q,n);
>             q = p+1;
>         }
>     }
>     n = i;
>     Reverse(q,n);
>     printf("\n");
>     return 0;
> }
> Thanks in advance.

I looked into this.  The problem seems to be that gdb-mi.el is
confused wrt which text typed by the user to send to GDB and which to
the program being debugged.

Here's the session on Windows:

  Reading symbols from d:/usr/eli/data/rev.exe...done.
  (gdb) break 22
  Breakpoint 1 at 0x4013ae: file rev.c, line 22.
  (gdb) start
  Temporary breakpoint 2 at 0x40136f: file rev.c, line 19.
  Starting program: d:/usr/eli/data/rev.exe 
  [New Thread 2120.0x165c]

  Temporary breakpoint 2, main () at rev.c:19
  19	    int i=0,n;

At this point, I see the source in another window with the arrow at
line 19 and the breakpoint I set at line 22.

Now:

  (gdb) continue
  Continuing.

  Breakpoint 1, main () at rev.c:22
  22	    p = q = s;			//  set breakpoint at this line.
  (gdb) print s
  $1 = "23-thread-info --thread 1 \000 ..."

That "23-thread-info --thread 1" thing is a command sent by gdb-mi.el
to GDB.  But since the debbuggee is reading stdin with fgets, the
command ends up in the buffer read by fgets.  Which explains why the
program doesn't stop when fgets is called: the call to fgets returns
immediately with the above command as its input.

I tried to work around this by commenting out the "-thread-info"
command sent here:

  (defun gdb-starting (_output-field)
    ;; CLI commands don't emit ^running at the moment so use gdb-running too.
    (setq gdb-inferior-status "running")
    (gdb-force-mode-line-update
     (propertize gdb-inferior-status 'face font-lock-type-face))
    (setq gdb-active-process t)
    (setq gud-running t)
    ;; GDB doesn't seem to respond to -thread-info before first stop or
    ;; thread exit (even in non-stop mode), so this is useless.
    ;; Behavior may change in the future.
    (gdb-emit-signal gdb-buf-publisher 'update-threads))  <<<<<<<<<<<<<

Then I do get a chance to type some text when the debuggee is stuck in
fgets.  But what winds up in the buffer read by fgets is

  -interpreter-exec console "TEXT"

where TEXT is what I typed.  Evidently, gdb-mi thinks that what I
typed is a GDB command, so it wraps it with -interpreter-exec.

The above was on MS-Windows.  On GNU/Linux, I see a slightly different
manifestation of what seems to be the same problem: there, I cannot
get the debuggee to continue after I type some text that is supposed
to be read by fgets.  Sounds like the input never gets to the
debuggee, or maybe the debuggee's stdin is not line-buffered for some
reason.  In any case, the call to fgets never returns.

So I no longer think this is a Windows-specific problem, and my
original assertion that it has to do with different buffering on
Windows seems to be incorrect.

Perhaps someone who knows more about GUD and comint in general could
chime in and find out what is wrong here.  Or at least explain what
should be done in gdb-mi to treat separately GDB commands and input to
the debuggee.  Evidently, the old gud-gdb way of running GDB did that
correctly.