From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 457E33858D37 for ; Thu, 27 Apr 2023 19:39:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 457E33858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca Received: from [172.16.0.192] (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id E3A281E128; Thu, 27 Apr 2023 15:39:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1682624350; bh=Q44iS0/WB1M2LWx0Eo0uC07TxypLKRUB+aMu9Wnew+s=; h=Date:Subject:To:References:From:In-Reply-To:From; b=LtdYyHAUuGF+HvUsH9SC3H3AcQxhjjuQ73YZGUcB6IxkEztnt6EjzxNeNPqHAYd89 Bo5JWbx+ob9q3X8XPT76exIXP1s1IO3gQ25k9sUw8m3aS0hUmNnadSXDJOHSFqCbMS pjsP2qRu6byNvtA+I7IqQ5dPYx/rDLFUupYKt9Aw= Message-ID: <9c4e4ce6-9986-1c3a-9885-f4f3388e95f6@simark.ca> Date: Thu, 27 Apr 2023 15:39:10 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH 4/5] gdb/testsuite: change newline patterns used in gdb_test Content-Language: fr To: Andrew Burgess , gdb-patches@sourceware.org References: <464e64e3a3483c228f0a73c778bcaf79e4595abd.1680293848.git.aburgess@redhat.com> From: Simon Marchi In-Reply-To: <464e64e3a3483c228f0a73c778bcaf79e4595abd.1680293848.git.aburgess@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,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 List-Id: On 3/31/23 16:20, Andrew Burgess via Gdb-patches wrote: > This commit makes two changes to how we match newline characters in > the gdb_test proc. > > First, for the newline pattern between the command output and the > prompt, I propose changing from '[\r\n]+' to an explicit '\r\n'. > > The old pattern would spot multiple newlines, and so there are a few > places where, as part of this commit, I've needed to add an extra > trailing '\r\n' to the pattern in the main test file, where GDB's > output actually includes a blank line. > > But I think this is a good thing. If a command produces a blank line > then we should be checking for it, the current test doesn't. > > Additionally, the existing pattern will happily match a partial > newline. There are a strangely large number of tests that end with a > random '.' character. Not matching a literal period, but matching any > single character, this is then matching half of the trailing newline > sequence, while the \[\r\n\]+ in gdb_test is matching the other half > of the sequence. I can think of no reason why this would be > intentional. All of these are cleaned up after this commit. > > The basic rule of gdb_test after this is that the expected pattern > needs to match everything up to, but not including the newline > sequence immediately before the GDB prompt. > > Second, while I was cleaning up newline matching in gdb_test, I've > also removed the '[\r\n]*' that was added to the start of the pattern > passed to gdb_test_multiple. > > The addition of this pattern adds no value. If the user pattern > matches at the start of a line then this would match against the > newline sequence. But, due to the '*', if the user pattern doesn't > match at the start of a line then this group doesn't care, it'll > happily match nothing. > > As such, there's no value to it, it just adds more complexity for no > gain, so I'm removing it. No tests will need updating as a > consequence of this part of the patch. Hi Andrew, Starting with this patch, I see many new failures in gdb.trace (using one of the gdbserver boards), for instance the first one being: FAIL: gdb.trace/collection.exp: collect args collectively: collected arg char Simon