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.

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