This is the mail archive of the
mailing list for the GDB project.
Re: Fix PR gdb/265, 64-bit pointers in Java
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.