From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25491 invoked by alias); 15 Dec 2014 15:41:04 -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 25482 invoked by uid 89); 15 Dec 2014 15:41:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,NO_DNS_FOR_FROM,T_RP_MATCHES_RCVD autolearn=no 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 Dec 2014 15:40:59 +0000 Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBFFeqAk032565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2014 10:40:53 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com sBFFeqAk032565 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com sBFFeqAk032565 Received: from mailsyshubprd03.lss.emc.com (mailsyshubprd03.lss.emc.com [10.253.24.25]) by maildlpprd06.lss.emc.com (RSA Interceptor); Mon, 15 Dec 2014 10:40:32 -0500 Received: from usendtaylorx2l.lss.emc.com (usendtaylorx2l.lss.emc.com [10.243.10.188]) by mailsyshubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBFFeabj010135; Mon, 15 Dec 2014 10:40:36 -0500 Received: by usendtaylorx2l.lss.emc.com (Postfix, from userid 26043) id D5CCC5DC503; Mon, 15 Dec 2014 10:40:35 -0500 (EST) Received: from usendtaylorx2l (localhost [127.0.0.1]) by usendtaylorx2l.lss.emc.com (Postfix) with ESMTP id D4E0C5DC2EC; Mon, 15 Dec 2014 10:40:35 -0500 (EST) To: Joel Brobecker cc: Stan Shebs , "gdb-patches@sourceware.org" Subject: Re: two agent expression nits (one line each) In-reply-to: <20141213134428.GF5457@adacore.com> References: <14583.1410458050@usendtaylorx2l> <547E24E5.8050908@earthlink.net> <20141213134428.GF5457@adacore.com> Comments: In-reply-to Joel Brobecker message dated "Sat, 13 Dec 2014 08:44:28 -0500." Date: Mon, 15 Dec 2014 15:41:00 -0000 Message-ID: <23074.1418658035@usendtaylorx2l> From: David Taylor X-RSA-Classifications: DLM_1, public X-Sentrion-Hostname: mailuogwprd02.lss.emc.com X-SW-Source: 2014-12/txt/msg00395.txt.bz2 Joel Brobecker wrote: > 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... The first part is pure documentation -- the description is correct but the summary line is wrong. The second part is implementation -- the consumed and produced fields are used to check for stack underflow and overflow. The fields are used by gdb and gdbserver for sanity checking the bytecode expression -- checking for underflow and overflow. The underflow check catches bad bytecode sequences generated by GDB. Since DEFOP has consumed as 0 when it is really 1, that means that GDB will think that there is more on the stack than there really is. So, if GDB generates a bytecode sequence that underflows it might not catch it. It does not currently generate bad sequences, so fixing it will merely help catch future lossage. As I recall, the overflow check is used by gdbserver to verify that it has sufficent stack space for the expression. The bad DEFOP line makes it think that the expression is using one more stack slot than reality. But, gdbserver has fairly generous bytecode stack space -- so unless the expression is really complicated, that won't happen. > Thanks! > -- > Joel