espressif/binutils-gdb
1
0
Fork 0
mirror of https://github.com/espressif/binutils-gdb.git synced 2025-06-03 13:23:00 +08:00
Code Issues Packages Projects Releases Wiki Activity

Fix bug in Ada number lexing

Browse Source 
On irc, Pedro pointed out that Ada couldn't properly handle
0xffffffffffffffff.  This used to work, but is a regression due to
some patches I wrote in the Ada lexer.  This patch fixes the bug.
This commit is contained in:
Tom Tromey
2022-04-08 10:11:58 -06:00
parent a8b7a13911
commit 36baf73637
3 changed files with 7 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
gdb/ada-lex.l
View File

@ -462,11 +462,11 @@ processInt (struct parser_state *par_state, const char *base0,
return FLOAT;
}
gdb_mpz maxval (ULONGEST_MAX / base);
gdb_mpz maxval (ULONGEST_MAX);
if (mpz_cmp (result.val, maxval.val) > 0)
error (_("Integer literal out of range"));
LONGEST value = result.as_integer<LONGEST> ();
ULONGEST value = result.as_integer<ULONGEST> ();
if ((value >> (gdbarch_int_bit (par_state->gdbarch ())-1)) == 0)
yylval.typed_val.type = type_int (par_state);
else if ((value >> (gdbarch_long_bit (par_state->gdbarch ())-1)) == 0)

3
gdb/testsuite/gdb.ada/literals.exp
View File

@ -34,3 +34,6 @@ gdb_test "print 2e1000" "Integer literal out of range"
gdb_test "print 16#ffff#" " = 65535"
gdb_test "print 16#f#e1" " = 240"
gdb_test "print 16#1#e10" " = 1099511627776"
gdb_test "print/x 16#7fffffffffffffff#" " = 0x7fffffffffffffff"
gdb_test "print 16#ffffffffffffffff#" " = -1"

3
gdb/testsuite/gdb.base/parse_number.exp
View File

@ -28,7 +28,8 @@ proc test_parse_numbers {} {
set val "0xffffffffffffffff"
if {$lang == "ada"} {
gdb_test "p/x $val" "Integer literal out of range"
gdb_test "p/x $val" " = 0xffffffffffffffff"
gdb_test "ptype $val" " = <8-byte integer>"
} elseif {$lang == "fortran"} {
gdb_test "p/x $val" " = 0xffffffff"
gdb_test "ptype $val" " = unsigned int"