From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3759 invoked by alias); 7 Mar 2013 14:06:01 -0000 Received: (qmail 3746 invoked by uid 22791); 7 Mar 2013 14:05:59 -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:05:28 +0000 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id DB.76.02411.6AE98315; Thu, 7 Mar 2013 15:05:27 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 09:05:26 -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:06: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> In-Reply-To: <513837B9.2070101@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/msg00286.txt.bz2 From: Yao Qi [yao@codesourcery.com] Sent: March 7, 2013 1:46 AM >=20 > 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. >=20 > 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=20 I suggest using whatever scheme is already being used. Thanks for the nice improvements Marc