From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id N9jfOI/zY2MIthMAWB0awg (envelope-from ) for ; Thu, 03 Nov 2022 12:59:59 -0400 Received: by simark.ca (Postfix, from userid 112) id DC5431E124; Thu, 3 Nov 2022 12:59:59 -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=nDsLZaty; 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=-6.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_MED,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.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 8C7EF1E0CB for ; Thu, 3 Nov 2022 12:59:59 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9B2B83858C3A for ; Thu, 3 Nov 2022 16:59:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9B2B83858C3A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1667494798; bh=dGKIGIAMHGwlLxCEpK6ZCFVJ6DDasj6DPAQXCZ4VEpk=; 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=nDsLZaty/xAMnYwsyqmQ1sSV0Egy1Ty5cZtpMZ5Jmi1D+OoGzmrswwhQepajLQcJz yVd7BkNSGZ5s/miyXC4FZcCyU4tuaqGZtXufb9tWlJOvJ8My5B+pHbzztMDdZ7D66P iE413aqcVN67ivVsszIm/VkC/R33qzqh+KIFhALk= Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 81E003858C60 for ; Thu, 3 Nov 2022 16:59:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 81E003858C60 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 F0BAA1E0CB; Thu, 3 Nov 2022 12:59:36 -0400 (EDT) Message-ID: Date: Thu, 3 Nov 2022 12:59:36 -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: [PATCHv2] 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> <717de14c-8b25-6691-5c0a-0b779997b742@redhat.com> In-Reply-To: <717de14c-8b25-6691-5c0a-0b779997b742@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 10:30, Bruno Larsen wrote: > On 03/11/2022 14:06, Simon Marchi wrote: >> >> 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. > > That makes sense. This is my first time working with gdbserver, so everything here is news to me.  Updated version: > > --- > >     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 Thanks: Approved-By: Simon Marchi Simon