From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2310 invoked by alias); 8 Mar 2013 15:49:14 -0000 Received: (qmail 2302 invoked by uid 22791); 8 Mar 2013 15:49:13 -0000 X-SWARE-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from usevmg21.ericsson.net (HELO usevmg21.ericsson.net) (198.24.6.65) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 08 Mar 2013 15:48:42 +0000 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id C5.CE.02411.9580A315; Fri, 8 Mar 2013 16:48:41 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0318.004; Fri, 8 Mar 2013 10:48:40 -0500 From: Marc Khouzam To: 'Yao Qi' CC: "'gdb-patches@sourceware.org'" Subject: RE: [PATCH 1/4] Fix dprintf bugs Date: Fri, 08 Mar 2013 15:49:00 -0000 Message-ID: References: <1361192891-29341-1-git-send-email-yao@codesourcery.com> <1362057362-25324-1-git-send-email-yao@codesourcery.com> ,<513837B9.2070101@codesourcery.com> ,<5138A5CC.5070301@codesourcery.com> <5138AB05.8090403@codesourcery.com> In-Reply-To: <5138AB05.8090403@codesourcery.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2013-03/txt/msg00380.txt.bz2 > -----Original Message----- > From: Yao Qi [mailto:yao@codesourcery.com]=20 > Sent: Thursday, March 07, 2013 9:58 AM > To: Marc Khouzam > Cc: gdb-patches@sourceware.org > Subject: Re: [PATCH 1/4] Fix dprintf bugs >=20 > On 03/07/2013 10:48 PM, Marc Khouzam wrote: > > So, I'm suggesting that sending an MI event from GDB to the=20 > frontend for > > every dprintf hit is too much. Does the same argument hold=20 > for async > > remote notifications? For efficiency, I'm thinking that=20 > 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=20 > the agent > > for the current hit count. This would cut down on the communication > > from agent to GDB when using dprintf. >=20 > If we use async remote notification for hit count update, of course,=20 > GDBserver can't report *every* hit count update to GDB, which is=20 > relatively expensive. GDBserver shouldn't send new async remote=20 > 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