From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3756 invoked by alias); 12 Nov 2007 23:26:56 -0000 Received: (qmail 3744 invoked by uid 22791); 12 Nov 2007 23:26:55 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 12 Nov 2007 23:26:51 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id D6F5E3C079; Mon, 12 Nov 2007 15:08:26 -0800 (PST) Subject: Re: New scope checking patch From: Michael Snyder To: Rob Quill Cc: gdb-patches@sourceware.org In-Reply-To: References: Content-Type: text/plain Date: Mon, 12 Nov 2007 23:26:00 -0000 Message-Id: <1194909466.12695.23.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-4.fc7) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2007-11/txt/msg00233.txt.bz2 On Mon, 2007-11-12 at 16:29 +0000, Rob Quill wrote: > Hi all, > > The attached patch adds the ability to evaluate whether expressions > are in scope without giving an error message. For example, if you were > using a command file to control GDB then it it may not be ideal that > the script stop executing due to a variable not being in scope at > given position. That's great! I've often wanted something like that. > > This patch allows you to say (for example) > > while(the program is not finished) > { > if($in_scope(x)) print x; > step; > } > > which would step through he whole program and print all the values of > x where x is valid, and just continue stepping where it is not valid. > > The bulk of the patch is changes to the evaluate_subexp functions in eval.c > > The following cases are cases which the core is written for, but have > not been tested yet: > > case OP_SCOPE: > case OP_REGISTER: > case OP_STRING: > case OP_OBJC_NSSTRING: /* Objective C Foundation > case OP_BITSTRING: > case UNOP_MEMVAL: > case UNOP_MEMVAL_TLS: > case OP_OBJC_SELF > > These cases have not been tested as I am unsure of code or commands > which would allow me to test them. If anyone has any suggestions then > that is greatly appreciated. > > The following cases are unimplemented as I am unsure of how to check > the scope of these expressions. Any advice you have is greatly > appreciated. > > case OP_ARRAY: > case TERNOP_SLICE: > case TERNOP_SLICE_COUNT: > case TERNOP_COND: > case OP_OBJC_SELECTOR: > case OP_OBJC_MSGCALL: > case OP_FUNCALL: > case OP_F77_UNDETERMINED_ARGLIST: > case STRUCTOP_PTR: > case STRUCTOP_MEMBER: > case STRUCTOP_MPTR: > // case TYPE_CODE_METHODPTR: > // case TYPE_CODE_MEMBERPTR: > case MULTI_SUBSCRIPT: > case UNOP_IND: > > For example, I think for a function call the way to check scope should > be to check that there is a function in scope with that name, and that > all the parameters are in scope. However, I am unsure how to implement > this. > > TYPE_CODE_METHODPTR and TYPE_CODE_MEMBERPTR are commented out as they > are supposedly redefinitions of two other cases (greater than and less > than operators, I believe) > > I should also point out that expression are evaluated without side > effects, so that, for example $in_scope(a = b) will return 1 if a and > b are in scope, but will not change the value of a. > > There is a caveat with the patch which is as follows. If a variable is > not in scope then the expression parser in c-exp.y inserts a value 0 > into the expression tree. When the scope checking function sees a 0 > expression in the tree it will return 0, to indicate not in scope. > However, in the general case it should be true that all literals are > in scope. However, due to the above caveat $in_scope(0) will return 0, > any any other literal will return 1. > > This also affects compound expressions that involve the literal 0. For > example, $in_scope(0+3) will return 0, as an expression with a binary > operator is considering in scope iff both of its operands are in > scope. > > Any thoughts on the patch are greatly appreciated. > > Thanks. > > Rob Quill