RE: [PATCH 1/4] Fix dprintf bugs

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

> -----Original Message-----
> From: Yao Qi [mailto:yao@codesourcery.com] 
> Sent: Thursday, March 07, 2013 9:58 AM
> To: Marc Khouzam
> Cc: gdb-patches@sourceware.org
> Subject: Re: [PATCH 1/4] Fix dprintf bugs
> 
> On 03/07/2013 10:48 PM, Marc Khouzam wrote:
> > 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.
> 
> If we use async remote notification for hit count update, of course, 
> GDBserver can't report *every* hit count update to GDB, which is 
> relatively expensive.  GDBserver shouldn't send new async remote 
> notification to GDB until the previous notification is ack'ed by GDB.

Again, I don't know the details of this communication so I might
be missing an important point.  Sending a new async notification
for a hit count change for dprintf, even if some of those will be
skipped when waiting for a GDB ack, sounds like a lot to me.
If I set a dprintf into a loop, there will be many printouts on
the target, but do we want to have so many async notifs sent
to GDB from the target?  Since we won't be sending MI events for
hit count changes for dprintf, do we need GDB to know dprintf
hit count 'live' or can we ask the target whenever that information
is actually needed?

Marc