From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11632 invoked by alias); 18 Sep 2014 13:38:21 -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 11619 invoked by uid 89); 18 Sep 2014 13:38:20 -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=ham 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; Thu, 18 Sep 2014 13:38:18 +0000 Received: from svr-orw-fem-03.mgc.mentorg.com ([147.34.97.39]) by relay1.mentorg.com with esmtp id 1XUbuY-0002Gf-6J from Yao_Qi@mentor.com ; Thu, 18 Sep 2014 06:38:14 -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; Thu, 18 Sep 2014 06:38:13 -0700 From: Yao Qi To: David Taylor CC: "gdb@sourceware.org" Subject: Re: trace state variables -- what should be traced? References: <32355.1410551103@usendtaylorx2l> <87iokp4joy.fsf@codesourcery.com> <28917.1410790743@usendtaylorx2l> Date: Thu, 18 Sep 2014 13:38:00 -0000 In-Reply-To: <28917.1410790743@usendtaylorx2l> (David Taylor's message of "Mon, 15 Sep 2014 10:19:03 -0400") Message-ID: <87ioklyrw1.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/msg00064.txt.bz2 David Taylor writes: > 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. > That is correct. > Whether multiple values get stored or later ones overwrite or get > dropped is a target stub implmentation detail that GDB has no control This is not target stub implementation detail to me. See tracev in https://sourceware.org/gdb/current/onlinedocs/gdb/Bytecode-Descriptions.html tracev (0x2e) n: =E2=87=92 a Record the value of trace state variable number n in the trace buffer. target stub shouldn't drop the value nor overwrite the value, because of the verb "Record" here. IOW, once target stub sees tracev, it has to save or record the value of TSV somewhere. This is in the stub side. > over. Further, other than the case of gdbserver, even if multiple get > stored, GDB has no control over which one gets returned. GDB doesn't have to control over which one gets returned. GDB only gets the 'correct' value from the target stub. See test case gdb.trace/tsv.exp, - tvariable $tvar5 =3D 15 - Set action to collect $tvar5 +=3D 1 - Check the value of $tvar5 (16) after the tracepoint is hit GDB doesn't know how many $tvar5 values are stored in one trace frame in stub side, but stub has to return the correct value 16. > > 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. remote protocol isn't aware of how tsv values are stored in a trace frame either. >> > 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 v= alue >> 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. The target stub has to provide the 'correct' (or latest) value of TSV, but it is nothing to do with how TSV values are stored. In short, how tsv values are stored in trace frame is the implementation details of different target stubs, but target stub has to provide the latest value of tsv when GDB sends requests to it. --=20 Yao (=E9=BD=90=E5=B0=A7)