[gdb/testsuite] Fix gdb.ada/literals.exp with aarch64
On aarch64-linux, I run into:
...
(gdb) print 16#ffffffffffffffff#^M
$7 = 18446744073709551615^M
(gdb) FAIL: gdb.ada/literals.exp: print 16#ffffffffffffffff#
...
while on x86_64-linux instead, I get:
...
(gdb) print 16#ffffffffffffffff#^M
$7 = -1^M
(gdb) PASS: gdb.ada/literals.exp: print 16#ffffffffffffffff#
...
We can easily reproduce this on x86_64-linux using:
...
$ gdb -q -batch -ex "set lang ada" -ex "set arch i386" \
-ex "print 16#ffffffffffffffff#"
$1 = -1
$ gdb -q -batch -ex "set lang ada" -ex "set arch aarch64" \
-ex "print 16#ffffffffffffffff#"
$1 = 18446744073709551615
...
With i386, we have:
...
(gdb) p int_bits
$3 = 32
(gdb) p long_bits
$4 = 32
(gdb) p long_long_bits
$5 = 64
...
and so in processInt we hit the fits-in-unsigned-long-long case where we use
as type long long:
...
/* Note: Interprets ULLONG_MAX as -1. */
yylval.typed_val.type = type_long_long (par_state);
...
With aarch64, we have instead:
...
(gdb) p int_bits
$1 = 32
(gdb) p long_bits
$2 = 64
(gdb) p long_long_bits
$3 = 64
...
and so in processInt we hit the fits-in-unsigned-long case where we use
as type unsigned long:
...
yylval.typed_val.type
= builtin_type (par_state->gdbarch ())->builtin_unsigned_long;
...
It's not clear why for ada we're using long long for the
fits-in-unsigned-long-long case.
Fix this by using unsigned long long for the fits-in-unsigned-long-long case,
meaning the new reference output is 18446744073709551615 instead of -1.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29416
2 files changed
