printfs output in wrong order in MI

> From:  Vladimir Prus <ghostcs.msu.su>
> Date:  Thu, 13 Apr 2006 11:02:23 +0400
> 
> Vladimir Prus wrote:
> 
> > 
> > Hi,
> > I'm seing strange behaviour of the
"printf" command if used in MI:
> > 
> >     (gdb)
> >     print &i
> >     &"print &i\n"
> >     ~"$1 = (int *) 0xbfc5f484\n"
> >     ^done
> >     (gdb)
> >     printf "%x", &i
> >     &"printf \"%x\",
&i\n"
> >     ^done
> >     (gdb)
> >     ~"bfc5f484"
> >     -interpreter-exec console "printf
\"%x\", &i"
> >     ^done
> >     (gdb)
> >     ~"bfc5f484"
> > 
> > The output of 'print' appears before
"^done", but the output of "printf"
> > appears *after* both "^done", and the
prompt, which makes it impossible to
> > reliably catch the output.
> ....
> > Any ideas why "printf" is so special?
> 
> I turns out that using 
> 
>   printf "%x\n", &i
> 
> (that is, adding "\n"), fixes the problem.
Still looks like a bug to me,
> though.

I think it's expected behavior: printf uses buffered
output, so if you
don't finish the line with a newline, the buffer is not
flushed.
Similar ``bugs'' can be seen in any C program that
displays characters
via printf without \n or fflush.

On Thursday 13 April 2006 11:55, Eli Zaretskii wrote:

> > > Any ideas why "printf" is so
special?
> >
> > I turns out that using
> >
> >   printf "%x\n", &i
> >
> > (that is, adding "\n"), fixes the
problem. Still looks like a bug to me,
> > though.
>
> I think it's expected behavior: printf uses buffered
output, 

Where in documentation is it stated that 'printf' uses
buffered output?

> so if you 
> don't finish the line with a newline, the buffer is
not flushed.
> Similar ``bugs'' can be seen in any C program that
displays characters
> via printf without \n or fflush.

Isn't it possible to auto-flush the buffer at the end of
"-interpreter-exec 
console" execution it's possible to flush the
buffers? I think it's 
reasonable to expect that *all* output of command wrapped in

"-interpreter-exec console" would appears before
the "^done" marker.

- Volodya

> From: Vladimir Prus <ghostcs.msu.su>
> Date: Thu, 13 Apr 2006 12:01:57 +0400
> Cc: gdbsources.redhat.com
> 
> > > (that is, adding "\n"), fixes
the problem. Still looks like a bug to me,
> > > though.
> >
> > I think it's expected behavior: printf uses
buffered output, 
> 
> Where in documentation is it stated that 'printf'
uses buffered output?

I'll welcome patches to document that, TIA.

> Isn't it possible to auto-flush the buffer at the end
of "-interpreter-exec 
> console" execution it's possible to flush the
buffers?

It is usually a performance tradeoff: GDB has no idea
whether a single
printf command is all you will want to print, or a part of a
block of
commands that your front end feeds one after the other.  In
the latter
case, flushing the buffers will be a performance hit.

The current code assumes that \n marks the end of the
values you want
to see output, so line buffering generally does The Right
Thing
(because, at least in interactive CLI usage, no one in their
right
mind will want to print strings unterminated by a newline:
it would
cause the next GDB prompt to not be the first thing on the
line).

> I think it's reasonable to expect that *all* output of
command
> wrapped in "-interpreter-exec console"
would appears before the
> "^done" marker.

Is it?  I wouldn't know; I'll let other front-end gurus to
comment on
that.

On Thu, Apr 13, 2006 at 12:25:45PM +0300, Eli Zaretskii
wrote:
> > I think it's reasonable to expect that *all*
output of command
> > wrapped in "-interpreter-exec console"
would appears before the
> > "^done" marker.
> 
> Is it?  I wouldn't know; I'll let other front-end
gurus to comment on
> that.

I agree.

Suppose you define a user defined command with multiple
printfs; even
from MI, we don't need to (or want to) flush between them. 
But when
-interpreter-exec return ^done, it ought to be ^done. 
Flushing the
output streams explicitly before then seems like a good idea
to me.

-- 
Daniel Jacobowitz
CodeSourcery