From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19703 invoked by alias); 15 Sep 2014 14:19:29 -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 19685 invoked by uid 89); 15 Sep 2014 14:19:27 -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_50,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mailuogwhop.emc.com Received: from mailuogwhop.emc.com (HELO mailuogwhop.emc.com) (168.159.213.141) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 15 Sep 2014 14:19:26 +0000 Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s8FEJKmh004101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Sep 2014 10:19:22 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s8FEJKmh004101 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s8FEJKmh004101 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by maildlpprd04.lss.emc.com (RSA Interceptor); Mon, 15 Sep 2014 10:19:05 -0400 Received: from usendtaylorx2l.lss.emc.com (usendtaylorx2l.lss.emc.com [10.243.10.188]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id s8FEJ6vM018085; Mon, 15 Sep 2014 10:19:06 -0400 Received: by usendtaylorx2l.lss.emc.com (Postfix, from userid 26043) id 85AEF5D380E; Mon, 15 Sep 2014 10:19:03 -0400 (EDT) Received: from usendtaylorx2l (localhost [127.0.0.1]) by usendtaylorx2l.lss.emc.com (Postfix) with ESMTP id E91145BA072; Mon, 15 Sep 2014 10:19:03 -0400 (EDT) To: Yao Qi cc: "gdb\@sourceware.org" Subject: Re: trace state variables -- what should be traced? In-reply-to: <87iokp4joy.fsf@codesourcery.com> References: <32355.1410551103@usendtaylorx2l> <87iokp4joy.fsf@codesourcery.com> Comments: In-reply-to Yao Qi message dated "Mon, 15 Sep 2014 00:00:13 -0400." MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Sep 2014 14:19:00 -0000 Message-ID: <28917.1410790743@usendtaylorx2l> From: David Taylor X-EMM-MHVC: 1 X-RSA-Classifications: public X-Sentrion-Hostname: mailuogwprd02.lss.emc.com X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00055.txt.bz2 Yao Qi wrote: > David Taylor writes: >=20 > > variables, it can be set with an aop_setv operation. Which value should > > be recorded? > > > > The old value? Or the new value? >=20 > I prefer both. But, only one is accessible. Even if the others are stored. only one will be seen by GDB. The target stub or gdbserver will search its data base of what was stored and if multiple are present, it will pick one -- probably either the first or the last; the others will be ignored. Whether multiple values get stored or later ones overwrite or get dropped is a target stub implmentation detail that GDB has no control over. Further, other than the case of gdbserver, even if multiple get stored, GDB has no control over which one gets returned. The remote protocol does not currently have a way of asking how many values got stored nor for asking for a specific one of the values. > > > > Currently the new value is always recorded and sometimes the old value > > is recorded as well. >=20 > Do you have an example that old value is *not* recorded? Sure. Typing: tvariable $tvar=3D100 maint agent $tvar =3D 78 produces: Scope: 0x500a290 Reg mask: 00 0 const8 78 2 setv 1 5 tracev 1 8 pop 9 end in GDB 7.8. > > Since the old value, when it is recorded, is always recorded prior to > > recording the new value, the new value overwrites the old value. >=20 > 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 va= lue > of this tsv may be read, but this bug was fixed by reading last matched > tsv This is gdbserver specific. Some stubs will behave differently. The GDB manual does not say what should be returned if multiple values are present. Nor what should happen if the stub is requested to store the value at the same address multiple times at the same tracepoint hit. > --=20 > Yao (=E9=BD=90=E5=B0=A7) David