RE: [PATCH 1/4] Fix dprintf bugs

[Marc Khouzam <marc.khouzam@ericsson.com>]

From: Yao Qi [yao@codesourcery.com]
Sent: March 7, 2013 1:46 AM
> 
> 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.

I was actually thinking of keeping the hit count being updated but
simply not sending the MI event for it.  I'm under the impression
that updating the hit count is not expensive, so having that information
available can be useful.  What bothers me is the very many MI
events being sent to the frontend.  If the hit count is not reported
by an MI event for dprintf, its value can still be obtained by
the frontend through -break-list for example.

For the agent-style dprintf though, I'm guessing that the hit count
is not being updated to avoid communication with GDB?  This
scenario already had to be handled for normal breakpoints and 
I suggest using whatever scheme is already being used.

Thanks for the nice improvements

Marc