From: Andrew Burgess <aburgess@redhat.com>
To: gdb-patches@sourceware.org
Cc: Andrew Burgess <aburgess@redhat.com>
Subject: [PATCHv2 3/3] gdb: improve error reporting from expression parser
Date: Tue, 2 Jan 2024 14:43:13 +0000 [thread overview]
Message-ID: <27b42f0c67b536beaf4afd05d5dd748524357c9d.1704206350.git.aburgess@redhat.com> (raw)
In-Reply-To: <cover.1704206350.git.aburgess@redhat.com>
This commits changes how errors are reported from the expression
parser. Previously, parser errors were reported like this:
(gdb) p a1 +}= 432
A syntax error in expression, near `}= 432'.
(gdb) p a1 +
A syntax error in expression, near `'.
The first case is fine, a user can figure out what's going wrong, but
the second case is a little confusing; as the error occurred at the
end of the expression GDB just reports the empty string to the user.
After this commit the first case is unchanged, but the second case now
reports like this:
(gdb) p a1 +
A syntax error in expression, near the end of `a1 +'.
Which I think is clearer. There is a possible issue if the expression
being parsed is very long, GDB will repeat the whole expression. But
this issue already exists in the standard case; if the error occurs
early in a long expression GDB will repeat everything after the syntax
error. So I've not worried about this case in my new code either,
which keeps things simpler.
I did consider trying to have multi-line errors here, in the style
that gcc produces, with some kind of '~~~~~^' marker on the second
line to indicate where the error occurred; but I rejected this due to
the places in GDB where we catch an error and repackage the message
within some longer string, I don't think multi-line error messages
would work well in that case. At a minimum it would require some
significant work in order to make all our error handling multi-line
aware.
I've added a couple of extra tests in gdb.base/exprs.exp.
---
gdb/parse.c | 6 +++++-
gdb/parser-defs.h | 4 ++++
gdb/testsuite/gdb.base/exprs.exp | 8 ++++++++
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/gdb/parse.c b/gdb/parse.c
index efac0dee1af..e8bb112177f 100644
--- a/gdb/parse.c
+++ b/gdb/parse.c
@@ -252,7 +252,11 @@ parser_state::parse_error (const char *msg)
if (this->prev_lexptr)
this->lexptr = this->prev_lexptr;
- error (_("A %s in expression, near `%s'."), msg, this->lexptr);
+ if (*this->lexptr == '\0')
+ error (_("A %s in expression, near the end of `%s'."),
+ msg, this->start_of_input);
+ else
+ error (_("A %s in expression, near `%s'."), msg, this->lexptr);
}
\f
diff --git a/gdb/parser-defs.h b/gdb/parser-defs.h
index 4d40245228b..34673787ef0 100644
--- a/gdb/parser-defs.h
+++ b/gdb/parser-defs.h
@@ -152,6 +152,7 @@ struct parser_state : public expr_builder
expression_context_block (context_block),
expression_context_pc (context_pc),
lexptr (input),
+ start_of_input (input),
block_tracker (tracker),
comma_terminates ((flags & PARSER_COMMA_TERMINATES) != 0),
parse_completion (completion),
@@ -288,6 +289,9 @@ struct parser_state : public expr_builder
Currently used only for error reporting. */
const char *prev_lexptr = nullptr;
+ /* A pointer to the start of the full input, used for error reporting. */
+ const char *start_of_input = nullptr;
+
/* Number of arguments seen so far in innermost function call. */
int arglist_len = 0;
diff --git a/gdb/testsuite/gdb.base/exprs.exp b/gdb/testsuite/gdb.base/exprs.exp
index 79ae905fccf..8c85b579b9d 100644
--- a/gdb/testsuite/gdb.base/exprs.exp
+++ b/gdb/testsuite/gdb.base/exprs.exp
@@ -275,3 +275,11 @@ gdb_test "print null_t_struct && null_t_struct->v_int_member == 0" \
# Regression test for unusual function-call parse that caused a crash.
gdb_test "print v_short++(97)" \
"cast the call to its declared return type"
+
+# Test for a syntax error at the end of an expression.
+gdb_test "print v_short + " \
+ "A syntax error in expression, near the end of `v_short \\+'\\."
+
+# Test for a syntax error in the middle of an expression.
+gdb_test "print v_short =}{= 3" \
+ "A syntax error in expression, near `\\}\\{= 3'\\."
--
2.25.4
next prev parent reply other threads:[~2024-01-02 14:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-23 19:56 [PATCH 0/2] Changes to error reporting from the " Andrew Burgess
2023-12-23 19:56 ` [PATCH 1/2] gdb: improve error reporting from " Andrew Burgess
2023-12-28 19:12 ` John Baldwin
2023-12-23 19:56 ` [PATCH 2/2] gdb: don't try to style content in error calls Andrew Burgess
2024-01-02 14:43 ` [PATCHv2 0/3] Changes to error reporting from the expression parser Andrew Burgess
2024-01-02 14:43 ` [PATCHv2 1/3] gdb: don't try to style content in error calls Andrew Burgess
2024-01-03 19:50 ` John Baldwin
2024-01-02 14:43 ` [PATCHv2 2/3] gdb: merge error handling from different expression parsers Andrew Burgess
2024-01-02 15:01 ` Lancelot SIX
2024-01-03 9:39 ` Andrew Burgess
2024-01-02 14:43 ` Andrew Burgess [this message]
2024-01-03 19:52 ` [PATCHv2 0/3] Changes to error reporting from the expression parser John Baldwin
2024-01-04 9:43 ` Andrew Burgess
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=27b42f0c67b536beaf4afd05d5dd748524357c9d.1704206350.git.aburgess@redhat.com \
--to=aburgess@redhat.com \
--cc=gdb-patches@sourceware.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