From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27724 invoked by alias); 2 Dec 2014 20:45:38 -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 27567 invoked by uid 89); 2 Dec 2014 20:45:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: elasmtp-spurfowl.atl.sa.earthlink.net Received: from elasmtp-spurfowl.atl.sa.earthlink.net (HELO elasmtp-spurfowl.atl.sa.earthlink.net) (209.86.89.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 02 Dec 2014 20:45:32 +0000 Received: from [68.104.56.205] (helo=macbook2.local) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1XvuK5-0000PX-WA; Tue, 02 Dec 2014 15:45:26 -0500 Message-ID: <547E24E5.8050908@earthlink.net> Date: Tue, 02 Dec 2014 20:45:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: David Taylor , "gdb-patches@sourceware.org" Subject: Re: two agent expression nits (one line each) References: <14583.1410458050@usendtaylorx2l> In-Reply-To: <14583.1410458050@usendtaylorx2l> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da940193823ff8faec775469eb5a3ab6668b9350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-IsSubscribed: yes X-SW-Source: 2014-12/txt/msg00036.txt.bz2 On 9/11/14, 10:54 AM, David Taylor wrote: > In gdb/doc/agentexpr.texi you''ll find the text: > > @item @code{setv} (0x2d) @var{n}: @result{} @var{v} > Set trace state variable number @var{n} to the value found on the top > of the stack. The stack is unchanged, so that the value is readily > available if the assignment is part of a larger expression. The > handling of @var{n} is as described for @code{getv}. > > The @item line and the following text do no agree with one another. I'm > guessing that the text is correct, in which case this line: > > @item @code{setv} (0x2d) @var{n}: @result{} @var{v} > > should be changed to this: > > @item @code{setv} (0x2d) @var{n}: @var{v} @result{} @var{v} Yes, that is correct. > Additionally, in gdb/common/ax.def we find the line: > > DEFOP (setv, 2, 0, 0, 1, 0x2d) > >>>From the comment earlier in the file: > > Each line is of the form: > > DEFOP (name, size, data_size, consumed, produced, opcode) > [...] > CONSUMED is the number of stack elements consumed. > PRODUCED is the number of stack elements produced. > > which is saying that nothing is consumed and one item is produced. Both > should be 0 or both should be 1. Setting them both to 1 seems better > since if nothing is on the stack an error will occur. So, it should be > changed to: > > DEFOP (setv, 2, 0, 1, 1, 0x2d) Yes to this also. From the look of things, I cloned the getv definition and forgot to adjust it. Although technically an incompatible change to the bytecode language, anybody who tried to set a state variable within a larger expression was going to get odd behavior and/or stack overflow, while the common case of just setting the variable and discarding the result is unaffected. So I think we can just make the change directly, and perhaps add a brief note to NEWS, to make sure that target agents get updated. (Mentor has one in-house separate from gdbserver, plus at least two customers with their own agents.) Stan stan@codesourcery.com