From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32397 invoked by alias); 15 Sep 2014 04:04:41 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 32384 invoked by uid 89); 15 Sep 2014 04:04:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 15 Sep 2014 04:04:38 +0000 Received: from svr-orw-fem-03.mgc.mentorg.com ([147.34.97.39]) by relay1.mentorg.com with esmtp id 1XTNWl-000464-4V from Yao_Qi@mentor.com ; Sun, 14 Sep 2014 21:04:35 -0700 Received: from GreenOnly (147.34.91.1) by svr-orw-fem-03.mgc.mentorg.com (147.34.97.39) with Microsoft SMTP Server id 14.3.181.6; Sun, 14 Sep 2014 21:04:34 -0700 From: Yao Qi To: David Taylor CC: Subject: Re: trace state variables -- what should be traced? References: <32355.1410551103@usendtaylorx2l> Date: Mon, 15 Sep 2014 04:04:00 -0000 In-Reply-To: <32355.1410551103@usendtaylorx2l> (David Taylor's message of "Fri, 12 Sep 2014 15:45:03 -0400") Message-ID: <87iokp4joy.fsf@codesourcery.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00051.txt.bz2 David Taylor writes: > variables, it can be set with an aop_setv operation. Which value should > be recorded? > > The old value? Or the new value? I prefer both. > > Currently the new value is always recorded and sometimes the old value > is recorded as well. Do you have an example that old value is *not* recorded? > > Since the old value, when it is recorded, is always recorded prior to > recording the new value, the new value overwrites the old value. The old value and the new value are recorded in the different 'V' blocks of the traceframe, so the new value shouldn't overwrite the old value. There was a bug in GDB that it reads the first matched tsv, so the old value of this tsv may be read, but this bug was fixed by reading last matched tsv --=20 Yao (=E9=BD=90=E5=B0=A7)