From patchwork Tue Jan 2 14:43:13 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Burgess X-Patchwork-Id: 83148 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DEAEA3858C2F for ; Tue, 2 Jan 2024 14:44:28 +0000 (GMT) X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id B27B63858C41 for ; Tue, 2 Jan 2024 14:43:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B27B63858C41 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B27B63858C41 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704206607; cv=none; b=n+OwXRaeEggPbDY0CEyE/eQ5EN6eN0FPH6m0OHS+XhXrXjgP5oCrzgoXYauybETCJVe5mYFyus1Mh9fe5S4ZguXGpNl0Gkamlk6DViiDu61fu0hehaK8KRe6TAwuGqnyxgDnKBhKLoUrYIHDfhWLqhxlHfpwzKx4WMARL9tELug= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704206607; c=relaxed/simple; bh=/d4qAdmA9D3MzuFYWBXz1Fochos/RufnoeT9YmiOV3k=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=pfR5El7v8Ubu34OIaB8nSt0mZXpyg8mTz+iaShmobJnGJDhMhuSQZSWmKz/bTVijWf1Umur5bCC3NYzgBgkyQBPihosdF0k5DSg6sjrF/0x3XgGtIVR6ObJ4JFvssGQY4TA0JcchnSNIaFrx/KaCBqzZj3ombVTV63rijoGWtRs= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1704206605; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZJvurFoKnmqDD+71tP5J/D2F8WY3GmQ/KIEnw1/u6m0=; b=aogbbmvBRt3niqZrBFEWLxfFBxgQ6Vkzfh2L2ZMUyiVZfH59fQ/iGidPh/KPO8WHS/XDCl wNcOvkB//Qy8MX3c3IB2Zt/SEzpS9l/cZilDlJPER0bvSxwsKvAZlXwIecRcFpD8iqLPLX Hm07fm/g+kpl0hJEtkecT3qr742M/Kk= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-594--q7RBXKfM66jPNUW0gMQqg-1; Tue, 02 Jan 2024 09:43:24 -0500 X-MC-Unique: -q7RBXKfM66jPNUW0gMQqg-1 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-336992b0f37so6121209f8f.0 for ; Tue, 02 Jan 2024 06:43:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704206603; x=1704811403; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Aio5wV7xpoGXa/l6yOoW7ECWdu4KQHdIVDOOqeIyg38=; b=AQ4cYNWFVkH6TOna7tqKl7P04FbCOv7Xj34HYIXGVE4Whp9gilUNfM5h7Bkh7LxytJ 8dkeAwPFVFgAdVDAuSK+4cApDg0BktVfU/4UqrGHWmhRnpexQFK2ybaGYrJRFWUGofoJ gZ4cNkymNK3nD+9daM3FjPLr+417UyVcJ5hksdCu9ePNQmOGs+vsD0Wc4/8O6h7eFeBn TuT5kIdqWwgyFtzkaXHx8Wzl4ioKnqKfjxmu2SXfW7vLu+UnsdNPvjnG5/t0G+5nd+N4 Te5R6W/I0AOAcQ/iTA3OgZRjUeNabFYUt2/3EK+ysgyQY6bBZY9D4ausT9UeGYiltffs Z68w== X-Gm-Message-State: AOJu0Yy5tfX+yQtuFsF+DkgwqKOxsAbnaQex6WkunGC69t2n/7suCNcM dOq5vbRCJKxFY+ZuPKXCkAPJOo0tau3gaVkNro9BjlfuHlvR0uejZ2QvNinpCYs4HouuJc4Uyuv 1nYE94Zs0uucVGKQ4zjxkJ7qo2u5Do+CzQ1P5K5jTQolUYvVXQSqIXKM6QrcOnxt+d1vGrArw+o 2oCRzvLcpWl4fLWw== X-Received: by 2002:a05:600c:1987:b0:40d:5798:1797 with SMTP id t7-20020a05600c198700b0040d57981797mr6412969wmq.63.1704206602866; Tue, 02 Jan 2024 06:43:22 -0800 (PST) X-Google-Smtp-Source: AGHT+IEG/Videbpkw8rORaDZLfbyf5QOgl7Br2d8VD9dj/brYAl8Y9HdF6fc6jYYNkMEpF//I1SrZg== X-Received: by 2002:a05:600c:1987:b0:40d:5798:1797 with SMTP id t7-20020a05600c198700b0040d57981797mr6412962wmq.63.1704206602589; Tue, 02 Jan 2024 06:43:22 -0800 (PST) Received: from localhost (185.223.159.143.dyn.plus.net. [143.159.223.185]) by smtp.gmail.com with ESMTPSA id z5-20020a05600c0a0500b0040d81ca11casm13154799wmp.28.2024.01.02.06.43.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jan 2024 06:43:21 -0800 (PST) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCHv2 3/3] gdb: improve error reporting from expression parser Date: Tue, 2 Jan 2024 14:43:13 +0000 Message-Id: <27b42f0c67b536beaf4afd05d5dd748524357c9d.1704206350.git.aburgess@redhat.com> X-Mailer: git-send-email 2.25.4 In-Reply-To: References: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-11.8 required=5.0 tests=BAYES_00, DKIM_INVALID, DKIM_SIGNED, GIT_PATCH_0, KAM_DMARC_NONE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org 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); } 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'\\."