From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id nhsPDhMR22RwAQEAWB0awg (envelope-from ) for ; Tue, 15 Aug 2023 01:45:55 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=uU99lQmM; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 2A5CA1E0C2; Tue, 15 Aug 2023 01:45:55 -0400 (EDT) Received: from server2.sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 15F6F1E098 for ; Tue, 15 Aug 2023 01:45:53 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3272C3857730 for ; Tue, 15 Aug 2023 05:45:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3272C3857730 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1692078352; bh=1/xS16xdTTiBs3NiUxJSxucwMz/+tdCsuiYwn/3SBHc=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=uU99lQmMrUkq0jc8Pq255EZbYZWJSsg30rAooc9sAoUBnObBxbx2U/RqvFYzZ8BdA Yn+VhF7+rzAxNyoCVAt3T5DoDsInQtZmJeNaZ/2qrdlwo6woxO32bh0Vp2650VwZRA 0f42wzXy6DduOLqeQNHG3U4RRsLvMHbVVP6MNX/s= Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 5F05C3858422 for ; Tue, 15 Aug 2023 05:45:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5F05C3858422 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id B6F1621992; Tue, 15 Aug 2023 05:45:30 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id A0A6E138E2; Tue, 15 Aug 2023 05:45:30 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id ze0QJvoQ22QPXAAAMHmgww (envelope-from ); Tue, 15 Aug 2023 05:45:30 +0000 Message-ID: <6a1ecf4a-8d8e-b993-ddf8-0d8863aeba74@suse.de> Date: Tue, 15 Aug 2023 07:45:26 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb/testsuite: Improve testing of GDB's completion functions Content-Language: en-US To: Bruno Larsen , gdb-patches@sourceware.org References: <20230222091110.2995513-1-blarsen@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-10.8 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, SPF_HELO_NONE, SPF_PASS, TXREP 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.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Tom de Vries via Gdb-patches Reply-To: Tom de Vries Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 7/25/23 17:40, Bruno Larsen wrote: > On 15/07/2023 14:13, Tom de Vries wrote: >> On 2/22/23 10:11, Bruno Larsen via Gdb-patches wrote: >>> When looking at some failures of gdb.linespec/cp-completion-aliases.exp, >>> I noticed that when a completion test will fail, it always fails with a >>> timeout.  This is because most completion tests use gdb_test_multiple >>> and only add a check for the correct output.  This commit adds new >>> options for both, tab and command completion. >>> >>> For command completion, the new option will check if the prompt was >>> printed, and fail in this case. This is enough to know that the test has >>> failed because the check comes after the PASS path. For tab completion, >>> we have to check if GDB outputted more than just the input line, because >>> sometimes GDB would have printed a partial line before finishing with >>> the correct completion. >> >> This causes quite a few regressions with check-read1. >> >> For instance: >> ... >> (gdb) break baz(int, FAIL: gdb.cp/cpcompletion.exp: tab complete >> "break baz(int" >> double) Quit^M >> (gdb) >> ... > Hi! Sorry for taking so long to respond. I'd appreciate some help in > solving, if you have the time. >> >> Thanks, >> - Tom >> >>> --- >>>   gdb/testsuite/lib/completion-support.exp | 16 ++++++++++++++++ >>>   1 file changed, 16 insertions(+) >>> >>> diff --git a/gdb/testsuite/lib/completion-support.exp >>> b/gdb/testsuite/lib/completion-support.exp >>> index bf9c5ad352c..275f8874f15 100644 >>> --- a/gdb/testsuite/lib/completion-support.exp >>> +++ b/gdb/testsuite/lib/completion-support.exp >>> @@ -94,6 +94,9 @@ proc test_gdb_complete_tab_none { line } { >>>       -re "^$line_re$completion::bell_re$" { >>>           pass "$test" >>>       } >>> +    -re "$line_re\[^ \]+ $" { >>> +        fail "$test" >>> +    } >>>       } >>>         clear_input_line $test >>> @@ -108,11 +111,15 @@ proc test_gdb_complete_tab_unique { input_line >>> complete_line_re append_char_re } >>>         set test "tab complete \"$input_line\"" >>>       send_gdb "$input_line\t" >>> +    set partial_complete [string_to_regexp $input_line] >>>       set res 1 >>>       gdb_test_multiple "" "$test" { >>>       -re "^$complete_line_re$append_char_re$" { >>>           pass "$test" >>>       } >>> +    -re "$partial_complete\[^ \]+ $" { >>> +        fail "$test" >>> +    } > > This is the specific change that causes the failures. The thinking > behind it was that if we receive more characters, but not the whole > complete_line, we got a failure. Something like this could detect if we > have a unique - but wrong - suggestion or multiple options. This way it > doesn't have to go to timeout every time, because it was making clang > testing take too long. > > Is there any other way to detect if GDB is done with the suggestion? Or > can we detect that read1 is being used, so this gets special cased? > The purpose of read1 is to reliably exercise FAILs in the test-suite, that are otherwise only occasionally occurring (see also "Race detection" in gdb/testsuite/README). It's typically a test-case problem where it passes or fails depending on how fast the input arrives. When read1 finds such a FAIL, we want to fix it because we want deterministic results. So, I'd say the relevant question is: did the change make the related test-cases racy, and does special casing try to hide the race? Thanks, - Tom