[gdb/testsuite] Fix gdb.ada/literals.exp with aarch64
authorTom de Vries <tdevries@suse.de>
Sat, 30 Jul 2022 06:02:20 +0000 (08:02 +0200)
committerTom de Vries <tdevries@suse.de>
Sat, 30 Jul 2022 06:02:20 +0000 (08:02 +0200)
commit61b9faef51ddd40f9e6de0e41b66c41cd943d868
treeffe54c638d6e6a4859ba371fcfb8ee602d6514d3
parent7900b17e334b114ff149c5a3da7884e6ab3f7136
[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
gdb/ada-lex.l
gdb/testsuite/gdb.ada/literals.exp