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 0441D3858D37 for ; Thu, 3 Nov 2022 13:06:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0441D3858D37 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 [10.0.0.11] (unknown [217.28.27.60]) (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 4E7F11E0D3; Thu, 3 Nov 2022 09:06:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1667480769; bh=kxDW4vkXvDye8i0Q/SFVcFsYCv1DnQl5oB0/iRaxhRI=; h=Date:Subject:To:References:From:In-Reply-To:From; b=jbpSVwbbrs+irR0rWPD6E2NmQ8s6rySnXAPvJ7pJ0Eu06fKTKculKnKumwYmXB9zn pxDucbZ3HvmNjrV8A7k3ff91IUibpk3gBCsc4H/dECnya1Qoekd+78QRf2ENQwBXkx +WU5MTbhsosWaECDMIy9oXubaDSoRSjj/Y7SXEvY= Message-ID: Date: Thu, 3 Nov 2022 09:06:08 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCH] gdb/testsuite: add KFAILs to gdb.reverse/step-reverse.exp Content-Language: en-US To: Bruno Larsen , gdb-patches@sourceware.org References: <1d743da0-278c-f800-10a0-d6aaa7995a92@simark.ca> <20221103090836.320197-1-blarsen@redhat.com> From: Simon Marchi In-Reply-To: <20221103090836.320197-1-blarsen@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-11.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,SPF_HELO_PASS,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 List-Id: On 11/3/22 05:08, Bruno Larsen wrote: >> I don't know the reverse stuff well, but the explanation makes sense. >> Do you plan on tackling this bug? If not, can you file a bug and add a >> kfail? > > Sure, I do plan on tackling this at some point, but I don't know when > that will be, so I filed the bug, and this is the patch to add the > KFAILs, thoughts? > > --- > > Recent changes to gdb.reverse/step-reverse.exp revealed the latent bug > PR record/29745, where we can't skip one funcion forward if we're using > native-gdbserver. This commit just adds kfails to the test. > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29745 > --- > gdb/testsuite/gdb.reverse/step-reverse.exp | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/gdb/testsuite/gdb.reverse/step-reverse.exp b/gdb/testsuite/gdb.reverse/step-reverse.exp > index c28e1f6db4f..37e80a7d337 100644 > --- a/gdb/testsuite/gdb.reverse/step-reverse.exp > +++ b/gdb/testsuite/gdb.reverse/step-reverse.exp > @@ -31,6 +31,7 @@ if { [prepare_for_testing "failed to prepare" $testfile $srcfile] } { > } > > runto_main > +set using_gdbserver [target_is_gdbserver] > > if [supports_process_record] { > # Activate process record/replay > @@ -273,11 +274,25 @@ if { "$step_out" == 1 } { > # Step forward over recursion again so we can test stepping over calls > # inside the recursion itself. > gdb_test_no_output "set exec-dir forward" "forward again to test recursion" > +if {$using_gdbserver} { > + # gdbserver doesn't record the change of return pointer, so we can't > + # next forward over functions. > + setup_kfail gdb/29745 *-*-* There's one thing bugging me in your explanation: as far as I know, gdbserver does any recording, with the built-in GDB recorder (i.e. not btrace). So we probably shouldn't say "gdbserver doesn't record", as it's not meant to record in the first place. That would mean the problem is within GDB, when using the remote target. And the check for the kfail should therefore use gdb_is_target_remote instead of target_is_gdbserver. Simon