msymbols being truncated to 32 bits.

[Michael Snyder]

OK, this is twice now that I've run into this.  I thought at first
that it was because I'm dealing with a harvard architecture, but
now I think it's just because there are some old 32-bit assumptions
still lying around in GDB, and I'm dealing with a 64-bit target.

Here's the deal.  I say "print top" in nodebug.exp, and I get
the address truncated to 32 bits.  After poking around a bit, 
I find that the expression parser has actually parsed this 
as a long (and then cast it to a function pointer.

Looking at parse.c, I find a function "write_exp_msymbol", 
which puts an msymbol onto the expression stream as an OP_LONG.
The comments for OP_LONG in expression.h say that it's followed
by a type, and then a long constant.  So there's my 32-bit
truncation.

Interestingly, right after OP_LONG in expression.h comes
OP_DOUBLE, and in 1996 Stu Grossman changed the argument
of OP_DOUBLE from a "double" to a "doublest".  He did not
simultaneously change the argument of OP_LONG to a longest.

Nor is there an OP_LONGEST.

So I'm wondering whether we should:
  1) change the argument of OP_LONG to longest, or
  2) add a new OP_LONGEST operator.

Anybody have any thoughts?  JimB -- you're our expression
parser expert.  ;-)

Michael