This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] mt set per-command remote-packets on|off
- From: Yao Qi <yao at codesourcery dot com>
- To: Doug Evans <dje at google dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>
- Date: Wed, 11 Dec 2013 09:07:13 +0800
- Subject: Re: [PATCH] mt set per-command remote-packets on|off
- Authentication-results: sourceware.org; auth=none
- References: <yjt2k3ftxy6y dot fsf at ruffy dot mtv dot corp dot google dot com> <5296DDC9 dot 2090103 at codesourcery dot com> <CADPb22T3Z1+sK7+KyoBiX-fCf1yZpK4Mntc3xVcyN6w6fkhOUw at mail dot gmail dot com>
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 (éå)