gdb p or x/s downcasts u64s to u32s

[m4b]

Repro

If you try to print a region of memory via x/s (say looking at a string slice), gdb truncates the value to a u32. Hence, if the value is a u64, it downcasts to a u32, and gives you an invalid region.

For example, supposing the memory region is 0x5555557e8cc0, then gdb (incorrectly) tells us this is equivalent to 1434356928 in decimal if we p this value, whereas it is actually 93824994938048

This is serious, as one cannot print regions of memory greater than a u32, and when one does, that region is truncated to a smaller value (and hence not the region you want to see).

GDB log illustrating the bug:

(gdb) p 0x5555557e8cc0
$10 = 1434356928
(gdb) x/s $10
0x557e8cc0: <error: Cannot access memory at address 0x557e8cc0>
(gdb) p/x $10
$11 = 0x557e8cc0
(gdb) p 0x5555557e8cc0
$12 = 1434356928
(gdb) p/x (uint64_t) $10
syntax error in expression, near `$10'.
(gdb) p/x ((uint64_t) $10)
syntax error in expression, near `$10)'.
(gdb) expr ((uint64_t) $10)
No compiler support for language rust.
(gdb) p ((uint64_t) $10)
syntax error in expression, near `$10)'.
(gdb) p ((uint64_t*) $10)
syntax error in expression, near `) $10)'.
(gdb) p ($10 as u64)
$13 = 1434356928
(gdb) p ($10 as u64)
$14 = 1434356928
(gdb) p ($10 as u32)
$15 = 1434356928
(gdb) p ($10 as u16)
$16 = 36032
(gdb) p ($10 as u8)
$17 = 192
(gdb) 

[tromey]

Sorry about this. I think it's a bug in the lexer. I'll fix it soon, meanwhile I think you can use 0xffffu64 or something like that.

[m4b]

Don't be sorry, this patch is awesome :)

Sorry for the issue spam, just was using it heavily in a session, and wanted to record the various bumps in the experience

[tromey]

Your turn not to be sorry :) The bug reports are very helpful.

[tromey]

Now https://sourceware.org/bugzilla/show_bug.cgi?id=20110