Thanks for your good work. The problem I encountered on windows is just as
you have described.But on linux(i am running ubuntu 12.04 under virtualbox)
,it works for me.
Here is the session on linux:
Reading symbols from /home/darks/Reverse...done.
(gdb) b 22
Breakpoint 1 at 0x80485e4: file Reverse.c, line 22.
(gdb) start
Temporary breakpoint 2 at 0x8048586: file Reverse.c, line 12.
Starting program: /home/darks/Reverse

At this point, I see the source in another window with the black arrow at
line 12 and the red breakpoint at line 22.
then,

(gdb) cotinue
continuing.

At this point,Nothing changed in the source code window .The debuggee hung
and is waitting input. So i input some values in IO buffer window and press
RET,the gdb session shows:

(gdb)

Now, the arrow goes into line 22 and hits the breakpoint.
Then :

(gdb) continue
or doing this repeatly: (gdb) next
The debuggee works very well.it showed all of the output in the IO buffer
window and normally terminted at last. That's all, just for your
information only. Thanks.
2012/8/11 Eli Zaretskii <eliz@gnu.org>

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