RE: [PATCH 1/4] Fix dprintf bugs

[Marc Khouzam <marc dot khouzam at ericsson dot com>]

> On 03/07/2013 10:05 PM, Marc Khouzam wrote:
> > 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.
> 
> FAOD, are you suggesting that we still update hit count, but don't have
> to notify breakpoint-modified observer?

That is right.  Of course, I'm just making a suggestion.  I don't know
GDB well enough to know all the implications, but from a frontend 
point-of-view I believe this solution is best.

> > 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.
>
> We can use async remote notification here, to notify GDB that the hit
> count or other attributes of breakpoint/tracepoint are modified.  I've
> had some local patches to report to GDB that the hit count and
> traceframe usage of tracepoint is updated.  After pending async remote
> notification are patches approved, I'll post them out.

So, I'm suggesting that sending an MI event from GDB to the frontend for
every dprintf hit is too much.  Does the same argument hold for async
remote notifications?  For efficiency, I'm thinking that agent dprintf should
not report every hit to GDB; instead, when GDB wants to know the hit
count (e.g, because of a -break-list command), it would ask the agent
for the current hit count.  This would cut down on the communication
from agent to GDB when using dprintf.

Does that make sense?

Marc