From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23193 invoked by alias); 7 Mar 2013 14:49:30 -0000 Received: (qmail 23121 invoked by uid 22791); 7 Mar 2013 14:49:28 -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; Thu, 07 Mar 2013 14:48:58 +0000 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 3E.09.02411.9D8A8315; Thu, 7 Mar 2013 15:48:57 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 09:48:56 -0500 From: Marc Khouzam To: Yao Qi CC: "gdb-patches@sourceware.org" Subject: RE: [PATCH 1/4] Fix dprintf bugs Date: Thu, 07 Mar 2013 14: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> In-Reply-To: <5138A5CC.5070301@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/msg00289.txt.bz2 > 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. >=20 > 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=20 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 shou= ld 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