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: Doug Evans <dje at google dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>
- Date: Wed, 27 Nov 2013 16:47:04 -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> <878uw9z9aj dot fsf at fleche dot redhat dot com>
On Wed, Nov 27, 2013 at 3:58 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Doug" == Doug Evans <dje@google.com> writes:
>
> Doug> It adds "mt set per-command packet on|off", and is helpful
> Doug> in examining remote serial protocol issues.
>
> I'm curious what happens in target-async mode with a background command.
> I suppose the stats are associated with the subsequent command?
Depends on when the transactions happen.
I played with it in target-async mode - as you know I'm seeing some
poor gdbserver performance in target-async+non-stop.
The absolute counts are ok, it's just the deltas that can be off.
It's good enough for my intended usage.
> Also, not your problem I guess, but it this seems like this will do the
> wrong thing when there are multiple remote targets, since the accounting
> is per-remote. If you really want it to be per-command it seems that
> you might as well just make the stats be globals, not in remote_state.
Thought about that too.
I'd like having per-remote stats so I kept them in remote_state.
The per-command stats will just report one target (and get the deltas
wrong if the target ever switches during the command), but it's a
pretty rare event at the moment.
And if/when we start having multiple remote targets be more common I
was thinking of having a command to allow dumping all the stats
(should such a need ever arise - it may not).
I was thinking about at least printing ??? instead of negative values
for the deltas should they occur.
I may do that now.
> Doug>+ If we're communicating over a flaky channel and have to resent packets
>
> Typo, "resend".
Righto.