public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Enze Li <enze.li@hotmail.com>
To: gdb-patches@sourceware.org
Cc: enze.li@gmx.com, schwab@linux-m68k.org
Subject: [PATCH v2] gdb: add a numeric check after the exponent (PR cli/24124)
Date: Mon,  5 Sep 2022 21:57:36 +0800	[thread overview]
Message-ID: <OS3P286MB21526397E3DF295E7B788105F07F9@OS3P286MB2152.JPNP286.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <OS3P286MB2152D905FE0BAF74185E6CE1F07C9@OS3P286MB2152.JPNP286.PROD.OUTLOOK.COM>

PR cli/24124 points out that `b *804874d` or `b *804874f` gives output
`Invalid number "804874d".` or `Invalid number "804874f".`  And the
output of `b *804874e` is `Breakpoint 1 at 0xc480a`.

That is to say, when "e" or "E" appears after a decimal value, it will
be incorrectly parsed as a floating point number.  Importantly, this
parsing is not consistent with the C language.

The initial idea was to perform a "0x" or "0X" check of the address.
But Tom pointed out that the text after the "*" is an arbitrary
expression, not just an integer.  Therefore, I realized that this idea
was going in the wrong direction.

After digging a bit deeper, I found that the root cause of this problem
is that the lex_one_token function doesn't check for the case where the
exponent has no digits.  If we check this, GDB will not continue parsing
the invalid numbers.

Before this patch applied, things like

  (gdb) b *804874d
  Invalid number "804874d".
  (gdb) b *804874e
  Breakpoint 1 at 0xc480a
  (gdb) print 80d
  Invalid number "80d".
  (gdb) ptype 80d
  Invalid number "80d".
  (gdb) print 80e
  $1 = 80
  (gdb) ptype 80e
  type = double

The new behavior is

  (gdb) b *804874d
  Invalid number "804874d".
  (gdb) b *804874e
  Invalid number "804874e".
  (gdb) print 80d
  Invalid number "80d".
  (gdb) ptype 80d
  Invalid number "80d".
  (gdb) print 80e
  Invalid number "80e".
  (gdb) ptype 80e
  Invalid number "80e".

New in v2:

- Address Andreas's comments, avoid breaking the resolution of the sign
  of the exponent.
- Add test cases for exponent with sign.

Tested on x86_64-linux.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24124
---
 gdb/c-exp.y                         | 10 ++++++++++
 gdb/testsuite/gdb.base/commands.exp | 11 +++++++++++
 2 files changed, 21 insertions(+)

diff --git a/gdb/c-exp.y b/gdb/c-exp.y
index 61a61fcba09c..9827de9ad549 100644
--- a/gdb/c-exp.y
+++ b/gdb/c-exp.y
@@ -2752,6 +2752,7 @@ lex_one_token (struct parser_state *par_state, bool *is_quoted_name)
 	int got_dot = 0, got_e = 0, got_p = 0, toktype;
 	const char *p = tokstart;
 	int hex = input_radix > 10;
+	int exp_num = 0;
 
 	if (c == '0' && (p[1] == 'x' || p[1] == 'X'))
 	  {
@@ -2783,6 +2784,9 @@ lex_one_token (struct parser_state *par_state, bool *is_quoted_name)
 	      /* This is the sign of the exponent, not the end of the
 		 number.  */
 	      continue;
+	    /* This is the digit of the exponent.  */
+	    else if (got_e && *p >= '0' && *p <= '9')
+	      exp_num++;
 	    /* We will take any letters or digits.  parse_number will
 	       complain if past the radix, or if L or U are not final.  */
 	    else if ((*p < '0' || *p > '9')
@@ -2790,6 +2794,12 @@ lex_one_token (struct parser_state *par_state, bool *is_quoted_name)
 				  && (*p < 'A' || *p > 'Z')))
 	      break;
 	  }
+
+	/* If the exponent has no digits, it must be invalid.  There is
+	   no need to continue parsing.  */
+	if (got_e && exp_num == 0)
+	  error (_("Invalid number \"%s\"."), tokstart);
+
 	toktype = parse_number (par_state, tokstart, p - tokstart,
 				got_dot | got_e | got_p, &yylval);
 	if (toktype == ERROR)
diff --git a/gdb/testsuite/gdb.base/commands.exp b/gdb/testsuite/gdb.base/commands.exp
index 3eb4463cd1a5..10c4c2722901 100644
--- a/gdb/testsuite/gdb.base/commands.exp
+++ b/gdb/testsuite/gdb.base/commands.exp
@@ -278,6 +278,17 @@ proc_with_prefix breakpoint_command_test {} {
     gdb_test "continue" \
 	    "Breakpoint \[0-9\]*, factorial.*Now the value is 5"
     gdb_test "print value" " = 5"
+
+    gdb_test "break *804874d" "Invalid number.*" "804874d is an invalid number"
+    gdb_test "break *804874e" "Invalid number.*" "804874e is an invalid number"
+    gdb_test "print 80d" "Invalid number.*" "(print) 80d is an invalid number"
+    gdb_test "ptype 80d" "Invalid number.*" "(ptype) 80d is an invalid number"
+    gdb_test "print 80e" "Invalid number.*" "(print) 80e is an invalid number"
+    gdb_test "ptype 80e" "Invalid number.*" "(ptype) 80e is an invalid number"
+    gdb_test "print 80e0" " = 80" "(print) 80e0"
+    gdb_test "print 80e1" " = 800" "(print) 80e1"
+    gdb_test "print 80e+2" " = 8000" "(print) 80e+2"
+    gdb_test "ptype 80e-1" " = double" "(ptype) 80e-1"
 }
 
 # Test clearing the commands of several breakpoints with one single "end".
-- 
2.37.2


  parent reply	other threads:[~2022-09-05 13:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-04  8:36 [PATCH] " Enze Li
2022-09-04  8:42 ` Andreas Schwab
2022-09-04 10:01   ` Enze Li
2022-09-05 13:57 ` Enze Li [this message]
2022-09-21 18:12   ` [PATCH v2] " Tom Tromey
2022-09-22 14:09     ` Enze Li
2022-09-23 13:47       ` Tom Tromey
2022-10-02 12:15         ` Enze Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=OS3P286MB21526397E3DF295E7B788105F07F9@OS3P286MB2152.JPNP286.PROD.OUTLOOK.COM \
    --to=enze.li@hotmail.com \
    --cc=enze.li@gmx.com \
    --cc=gdb-patches@sourceware.org \
    --cc=schwab@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).