Re: [PATCH 1/4] Fix dprintf bugs

[Yao Qi <yao at codesourcery dot com>]

Marc, thanks for playing with dprintf and giving a lot useful comments 
and suggestions.


On 03/03/2013 10:21 AM, Marc Khouzam wrote:
> I'm still hesitant about the -break-modified event in that case
> though.  I believe the event is triggered because the hit count
> has changed.  For a normal bp, it makes sense to have this event
> in this case, since execution has stopped and only a single
> event will be seen (not exactly true for non-stop, but still
> makes sense, I think).  However, for dprintf which is meant to
> let the inferior continue to run, there could be quite many
> hit events very quickly.  Since we already have some feeback
> that the dprintf has hit through the actual printf string, I'm
> leaning towards not having that event for dprintf hits.

Right, the "hit count" is not very meaningful to dprintf.  I am fine not 
to update hit count for dprintf.

> Furthermore, this event is not being sent when using dprintf-style
> "agent" anyway.
>
> I also saw that conditions are now properly respected for dprintf-style
> "gdb" and "call".  That is great.  Conditions are still not respected for
> style "agent" but that is a separate issue I believe (PR 15180).

Right, PR 15180 is a separate problem.  It is not dprintf specific, in 
fact.  It is about target side commands execution respected for the 
target side conditions.

> I did notice that although commands cannot be set for dprintf from
> the CLI they are not blocked for MI:
>
> (gdb) interpreter-exec mi "-break-commands 1 hello"
> ^done
> (gdb) info b
> Num     Type           Disp Enb Address            What
> 1       dprintf        keep y   0x0000000000400570 in main() at loopfirst.cc:8
>          hello

I'll handle this in the new version.

--
Yao (éå)