Re: New scope checking patch

Michael Snyder
2007-11-12T23:26:56Z

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