From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27027 invoked by alias); 28 Nov 2013 00:47:14 -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 27018 invoked by uid 89); 28 Nov 2013 00:47:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_40,RDNS_NONE,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-ve0-f174.google.com Received: from Unknown (HELO mail-ve0-f174.google.com) (209.85.128.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 28 Nov 2013 00:47:12 +0000 Received: by mail-ve0-f174.google.com with SMTP id pa12so5580424veb.19 for ; Wed, 27 Nov 2013 16:47:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Z8qthFaYJ4CY1LusDYNMvekzge4bviZfNtKa2nZ+rYA=; b=IzwZzGLhWMu6/BGtIw7uza98fzvtsQLDp8Tcc7ZJJ7L2LQr1nGk+1Zpo2c/cx7xSJG e03kdPxV4KD+/N2YXJsndwtOwSdXosx7g8MNnOHdnfmkGyvVTfbRuc7zkZmbom6B7LvW t7SsoPCZ3tBEUzfyH+vMlhUo+k4q2K9pBY8yjYxFtLQgHQlQG53j3UKeSPU3sOb+UJzU UT/zQ9LejuwBAz42CA5f6sMXGhuj4OzGOhRjPwZLh5UpJliwYVBSmfsUq6d9fPjyOFvk PwZZeilGSJBj1In+ciVJsokhhbeb2a5cNvCvXUDV7RQ8TkRmTMoA+1zRzQ//FoKfPl1h oI7w== X-Gm-Message-State: ALoCoQkG3Prkvi51hPJJ+8PRoUAkMW/fNhtee4eBMZb3KBplkFguOD/pAKrZrQtHhZyK8K5IsMq9/iRrn11cbrKOh0Jr/A+1M2+6vHXNWBPvihrz2A7ekVhycggO0EbKsURELM5ZojXINsGh2G5UC2DookxAJKpndITdUmDnNL1C/cnPB7U5d2zRIZQeASYbI9rnMz8iAFVXbzZR1vEaV0PFzW3ZLzhq+Q== MIME-Version: 1.0 X-Received: by 10.220.184.70 with SMTP id cj6mr11319079vcb.23.1385599624396; Wed, 27 Nov 2013 16:47:04 -0800 (PST) Received: by 10.52.163.52 with HTTP; Wed, 27 Nov 2013 16:47:04 -0800 (PST) In-Reply-To: <878uw9z9aj.fsf@fleche.redhat.com> References: <878uw9z9aj.fsf@fleche.redhat.com> Date: Thu, 28 Nov 2013 01:36:00 -0000 Message-ID: Subject: Re: [PATCH] mt set per-command remote-packets on|off From: Doug Evans To: Tom Tromey Cc: gdb-patches Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg00868.txt.bz2 On Wed, Nov 27, 2013 at 3:58 PM, Tom Tromey wrote: >>>>>> "Doug" == Doug Evans 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.