From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29004 invoked by alias); 13 Dec 2014 13:44:31 -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 28993 invoked by uid 89); 13 Dec 2014 13:44:31 -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: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Sat, 13 Dec 2014 13:44:30 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 814811163B9; Sat, 13 Dec 2014 08:44:28 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SHvoBiq3O8ME; Sat, 13 Dec 2014 08:44:28 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 8C0241163A8; Sat, 13 Dec 2014 08:44:27 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 2229F40164; Sat, 13 Dec 2014 08:44:28 -0500 (EST) Date: Sat, 13 Dec 2014 13:44:00 -0000 From: Joel Brobecker To: Stan Shebs Cc: David Taylor , "gdb-patches@sourceware.org" Subject: Re: two agent expression nits (one line each) Message-ID: <20141213134428.GF5457@adacore.com> References: <14583.1410458050@usendtaylorx2l> <547E24E5.8050908@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <547E24E5.8050908@earthlink.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-12/txt/msg00310.txt.bz2 Hi Stan, > > 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.) Would you mind taking care of that for us? I kept that message around in the hope that I'd have a clearer picture with a little extra time, but I am still not sure whether you're just suggesting a documentation fix, or if you're saying we should fix the implementation... Thanks! -- Joel