From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5600 invoked by alias); 11 Dec 2013 01:08:54 -0000 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 Received: (qmail 5499 invoked by uid 89); 11 Dec 2013 01:08:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.5 required=5.0 tests=AWL,BAYES_00,GARBLED_BODY autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from Unknown (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 11 Dec 2013 01:08:50 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1VqYHz-0007Sj-Aa from Yao_Qi@mentor.com ; Tue, 10 Dec 2013 17:08:35 -0800 Received: from SVR-ORW-FEM-02.mgc.mentorg.com ([147.34.96.206]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Dec 2013 17:08:35 -0800 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server id 14.2.247.3; Tue, 10 Dec 2013 17:08:34 -0800 Message-ID: <52A7BAC1.9090900@codesourcery.com> Date: Wed, 11 Dec 2013 01:08:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Doug Evans CC: gdb-patches Subject: Re: [PATCH] mt set per-command remote-packets on|off References: <5296DDC9.2090103@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00399.txt.bz2 On 12/11/2013 05:12 AM, Doug Evans wrote: > > > Good point. OTOH going that route brings more complication that isn't > needed at the moment (rsp perf data*is* needed now). > [I finally have some(!) time to return to this.] That is good! :) > > >> > >> >IWBN to add a new interface target_print_statistics, and leave each target to decide what data to print. > > From a high level perspective the target collects the statistics, but > consumers will want to print them their own way. > I didn't want to go "whole hog" yet because it's not clear yet what > the different consumers are. > [And remote protocol performance is in real need of improvement so I > wanted to start solving that problem now.] > That is OK to me. I am eager to see collect rsp perf data through this and potential improvement, rather than designing an ideal interface. > >> > >> > >> > >>> >>diff --git a/gdb/remote.c b/gdb/remote.c >>> >>index 186c058..429a49c 100644 >>> >>--- a/gdb/remote.c >>> >>+++ b/gdb/remote.c >>> >>@@ -426,6 +426,14 @@ struct remote_state >>> >> >>> >> /* The state of remote notification. */ >>> >> struct remote_notif_state *notif_state; >>> >>+ >>> >>+ /* Statistics for measuring protocol efficiency. >>> >>+ Note: These record data at the protocol level, so to speak. >>> >>+ If we're communicating over a flaky channel and have to resent packets >>> >>+ that is not accounted for here. It's recommended to track resends, etc. >>> >>+ separately. */ >>> >>+ long packets_sent, packets_received; >>> >>+ long bytes_sent, bytes_received; >> > >> > >> >Use "unsigned long"? > > How about int? > If you prefer signed type here, "long" is fine. >>> >> >>> >>+/* Fetch the current packet statistics. */ >>> >>+ >>> >>+void >>> >>+get_remote_packet_stats (long *packets_sent, long *packets_received, >>> >>+ long *bytes_sent, long *bytes_received) >>> >>+{ >> > >> > >> >... In this way, the number of arguments of function can be reduced. > > It was done this way to separate the collector of the data from the > printer of the data. > If we later collect finer grained stats, callers that want a gross > number can still call this, and this function could sum up the pieces. > Even we just count these four, it is better to put them in a structure, and associate the structure instance with remote_state. -- Yao (齐尧)