Fix PR gdb/265, 64-bit pointers in Java

[Per Bothner]

Daniel Jacobowitz wrote:
> Well, it does not silently change the type for conforming input;
> integers will still be marked as integers.  The patch allows us to accept
> things like:
> (gdb) x/i 0x123456789
> 
> which really ought to work.

I'm not 100% convinced, but it's at least reasonable.

> If you disagree with me on that, which you certainly can :), then I
> would prefer to have a flag for parse_number saying it created an
> implicit long and cause errors if the expression being evaluated is a
> method call, etc.  I'm not convinced that's worth the trouble.

An idea: If it overflows, set the type to builtin_type_uint64, or some
similar type, but don't set it to java_type_long.  That way we still
get x/i 0x123456789 to do the expected, but we can (if we wanted to)
catch incorrectly passing 0x123456789 to a Java method.

This is similar to how G++ treets jint (__java_int), as a different
integer type than int, so it can can programs that try to incorrectly
pass an 'int' to a Java method.

If you change it to:

   if (type == java_int_type && n > (ULONGEST)0x80000000)
      type = builtin_type_uint64;

then that would satisfy me.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/