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 D64CD3858D1E for ; Tue, 2 May 2023 19:16:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D64CD3858D1E 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 5A8C51E0D3; Tue, 2 May 2023 15:16:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1683054984; bh=iTeAC87jJDRbOlRzvwS/SPfViM3QL1DUicRhdVuXGgI=; h=Date:Subject:To:References:From:In-Reply-To:From; b=Alq8orC2aXSrQ4K0E1e1UBOpt1LK/TZIDRw7Nx/C4RSAWulrP48c2qamtAybNUKGM wsU4zD6JgxmvSCK4zY6YhgMoci0AIXDwZU+t4QlCaTtXa0FUINjJV9aDYP66/VZJPp mEGU1MrpB0K6/yvSm+67udrwlJImb/C/d1X1EDkU= Message-ID: <9e159184-2a76-917d-6c2d-ad45a6228971@simark.ca> Date: Tue, 2 May 2023 15:16:23 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 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> <9c4e4ce6-9986-1c3a-9885-f4f3388e95f6@simark.ca> <87r0s49fa0.fsf@redhat.com> <55449bae-c9ea-4b04-f07e-a4ad2e3d6bf1@simark.ca> <46010910-4b1f-7322-e273-57a09b9f4669@simark.ca> <87leibad7g.fsf@redhat.com> From: Simon Marchi In-Reply-To: <87leibad7g.fsf@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 4/28/23 17:50, Andrew Burgess wrote: > Simon Marchi writes: > >> On 4/28/23 11:57, Simon Marchi via Gdb-patches wrote: >>>> I've pushed the patch below which fixes all the regressions I see when >>>> using the native-gdbserver board. >>>> >>>> I'm still testing with the native-extended-gdbserver board, but I'm a >>>> little short of time, so might not be able to fix any regressions that >>>> throws up until next week. So I've pushed this fix for now, and will >>>> follow up with any additional fixes I find later. >>>> >>>> Sorry for causing the regressions. >>> >>> Thanks, I'll let you know if there are more remaining failures. >>> >>> Simon >>> >> >> I still see these two, which are likely related: >> >> FAIL: gdb.trace/collection.exp: collect register locals collectively: run trace experiment: stop trace experiment > > I think we should accept this regression. Here's the gdb.log output: > > (gdb) PASS: gdb.trace/collection.exp: collect register locals collectively: run trace experiment: run trace experiment > tstop > Trace is not running. > (gdb) FAIL: gdb.trace/collection.exp: collect register locals collectively: run trace experiment: stop trace experiment > > I changed this test form this: > > gdb_test "tstop" \ > "\[\r\n\]+" \ > "stop trace experiment" > > to this: > > gdb_test_no_output "tstop" \ > "stop trace experiment" > > The 'Trace is not running.' error is what causes the test to fail. This > test has a bunch of other FAILs, one of which is the 'tstart' preceeding > the above 'tstop': > > (gdb) PASS: gdb.trace/collection.exp: collect register locals collectively: run trace experiment: advance to begin > tstart > locf has been optimized out of existence. > locd has been optimized out of existence. > Expression pieces exceed word size > (gdb) FAIL: gdb.trace/collection.exp: collect register locals collectively: run trace experiment: start trace experiment > > So clearly, the test script is expecting the tracing to start, but it > doesn't. Catching things like the above -- where we were missing a > warning/error from GDB was exactly the point of my patch -- so I think > this additional failure is acceptable. That makes sense (it would have been obvious if I had looked at it, but didn't really have time). I'll add it to my list of expected failures, since it's just the consequence of an existing failure. >> FAIL: gdb.trace/pending.exp: ftrace works: stop trace experiment > > I'm not able to reproduce this one. On my local machine the > pending_tracepoint_works proc (in pending.exp) exits early as (according > to the comment) the target was unable to install the fast tracepoint. > > Could you confirm that the 'tstart' test immediately preceding this > 'tstop' test passes successfully please, it's name will be: > > gdb.trace/pending.exp: ftrace works: start trace experiment > > If this FAILs then I think, like the one above then it's OK that the > corresponding tstop also FAILs. If you are seeing the 'tstart' PASS > then could you paste in the corresponding gdb.log snippet and I'll see > if I can spot the problem. The "start trace experiment" fails too, so it's probably the same thing as the previous one. Thanks for looking into it! Simon