From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 699 invoked by alias); 7 Jan 2013 15:39:33 -0000 Received: (qmail 647 invoked by uid 22791); 7 Jan 2013 15:39:32 -0000 X-SWARE-Spam-Status: No, hits=-7.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Jan 2013 15:39:23 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r07FdMcM009673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Jan 2013 10:39:22 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r07FdKEj012995; Mon, 7 Jan 2013 10:39:21 -0500 Message-ID: <50EAEC28.9040704@redhat.com> Date: Mon, 07 Jan 2013 15:39:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [PATCH 2/2] Compute traceframe usuage per tracepoint on demand. References: <1355276266-23163-1-git-send-email-yao@codesourcery.com> <1355276266-23163-3-git-send-email-yao@codesourcery.com> <50CEE3CF.8070904@codesourcery.com> In-Reply-To: <50CEE3CF.8070904@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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-01/txt/msg00108.txt.bz2 On 12/17/2012 09:20 AM, Yao Qi wrote: > On 12/12/2012 09:37 AM, Yao Qi wrote: >> + /* Compute the traceframe usage of tracepoint whose number is >> + NUM. */ >> + for (tframe = FIRST_TRACEFRAME (); >> + tframe->tpnum != 0; >> + tframe = NEXT_TRACEFRAME (tframe)) >> + if (tframe->tpnum == num) >> + traceframe_usage += tframe->data_size; >> + >> sprintf (own_buf, "V%" PRIu64 ":%" PRIu64 "", tpoint->hit_count, >> - tpoint->traceframe_usage); >> + traceframe_usage); > > It is incorrect for tracepoint with multiple locations, because multiple tracepoints in GDBserver have the same tracepoint number, and each tracepoint has its own traceframe usage. > > On 12/12/2012 09:37 AM, Yao Qi wrote: >> Then, I thought that we may use pointer to >> 'struct tracepoint' instead of tracepoint num in 'struct traceframe', >> but comments of 'struct traceframe' tell me that I shouldn't do this, >> "This object should be as small as possible". If we don't mind >> increasing 2 bytes (on 32-bit target) for each 'struct traceframe', > > Looks we have to go this way, in order to get the correct traceframe usage of each tracepoint in GDBserver. To avoid the size penalty on 64-bit, another option would be for gdbserver to maintain an internal tracepoint number, unique for each location, and for traceframes to record that instead of gdb tracepoint number. Did you try the other option of accounting for usage in add_traceframe_block? I suspect it may be simple and not add much more than a few instructions. > I'll post a new patch again. I may have missed it. Have you posted it? -- Pedro Alves