Re: DPrintf feedback

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Marc" == Marc Khouzam <marc.khouzam@ericsson.com> writes:

Marc> Such an approach may also help fix the "continue" problem
Marc> that Yao is trying to address.  I seem to recall that Hui had posted 
Marc> patches to add some kind of 'printf' tracepoint command.  Maybe that 
Marc> would be something that can help?

I thought this was subsumed by "set dprintf-style agent"?

Marc> Other issues I ran across are below.  I wasn't sure opening PRs was
Marc> the way to do since those issues may disappear if the current 
Marc> implementation is amended:

I think it is best to file PRs.  If a patch fixes them all, then that is
fine.  But if not, then this the only way to avoid losing track.

Marc> - Pagination is triggered for dprintf in CLI mode, at least when
Marc> using dprintf-style 'gdb'.

Maybe we need a new "gdb-unfiltered" setting?  Or we could disable
pagination entirely here, but that maybe leads to other issues.

Marc> - In Eclipse, the dprintf-style that makes sense is either 
Marc>   'call' or 'agent'.

I was surprised to hear this.  Could you say why?

Marc> - Output buffering is not behaving as a real printf.  For 
Marc>   example, if my program does
Marc>      printf("hello");
Marc>      printf("friend\n");
Marc> and I put a dprintf " my " on the second line, 
Marc> I would expect to see
Marc>    "hello my friend"
Marc> but instead I see
Marc>    " my hellofriend"
Marc> which shows that the dprintf string does not go to the same 
Marc> buffer as the real printfs, and is flushed earlier.
Marc> This also happens with the dprintf-style "agent"

Which other setting does this happen with?
I would expect it to work with "call" but not with "gdb".

You could hack around this by disabling buffering for stdout.
I'm not totally sure it is a bug for it to work the current way by
default.

Tom