From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Kb3qMdu8Y2MqoRMAWB0awg (envelope-from ) for ; Thu, 03 Nov 2022 09:06:35 -0400 Received: by simark.ca (Postfix, from userid 112) id BDD821E124; Thu, 3 Nov 2022 09:06:35 -0400 (EDT) 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=hO9cLsIz; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_MED,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from 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 RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 75E851E0D3 for ; Thu, 3 Nov 2022 09:06:35 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8411B3858C2D for ; Thu, 3 Nov 2022 13:06:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8411B3858C2D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1667480794; bh=LlY5VkCY5q3CrhnNJ94kO9kHlJILo+M7PJN8z5E/xCA=; 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=hO9cLsIzv+r2VY1RHfxOzMSHMO4PrljWQILrZuBP65Rbxcjg/h7s7Q1zy1tDpmBhN yQWIoKYIa5v0SNZlCZrwx43WAEAy30kZaMjkA3hIk+s9N7XG08iMHdwUXJ/gZ7VqJc XDyasUbRwly5cviTj2EsTuzsZUqPO/PzzpNWmzO4= 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 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) 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> In-Reply-To: <20221103090836.320197-1-blarsen@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" 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