From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id EAewKRatYmM5QxMAWB0awg (envelope-from ) for ; Wed, 02 Nov 2022 13:47:02 -0400 Received: by simark.ca (Postfix, from userid 112) id A88B21E124; Wed, 2 Nov 2022 13:47:02 -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=KgiVtvBn; 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 51F111E0D3 for ; Wed, 2 Nov 2022 13:47:02 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id EBD763857016 for ; Wed, 2 Nov 2022 17:47:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EBD763857016 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1667411221; bh=cJUIQaRkx0ACU92Hxb0Nn9gKYdWCXS97YicqblHhjUE=; 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=KgiVtvBnyoaejjNR54rd325hPG/GvIck3OaUoaZUDfikXV1T95KcK3pMz3rHW7pd7 31wk6fR+QCDqtZhAfUwHsjIfh3JAGDOGsGyZq3P7IL3BOhul8DjfII1BV/ViGgegGe /d/iKZ7LK6gJ3+Ky4P433P4SsZmSuSPBqIRbBsDc= Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 76D63385AC2D for ; Wed, 2 Nov 2022 17:46:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 76D63385AC2D Received: from [172.16.0.64] (192-222-180-24.qc.cable.ebox.net [192.222.180.24]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 1680C1E0D3; Wed, 2 Nov 2022 13:46:41 -0400 (EDT) Message-ID: <1d743da0-278c-f800-10a0-d6aaa7995a92@simark.ca> Date: Wed, 2 Nov 2022 13:46:40 -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 v4 2/2] gdb/reverse: Fix stepping over recursive functions Content-Language: fr To: Bruno Larsen , gdb-patches@sourceware.org References: <20221005103832.3163424-1-blarsen@redhat.com> <20221005103832.3163424-3-blarsen@redhat.com> <95cc9197-e54a-f6ea-8092-d6d0063c58a3@simark.ca> <4cc13e71-aa24-b66b-f8bc-1bb9b7e17b59@redhat.com> In-Reply-To: <4cc13e71-aa24-b66b-f8bc-1bb9b7e17b59@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/2/22 13:03, Bruno Larsen via Gdb-patches wrote: > On 25/10/2022 16:55, Simon Marchi wrote: >> On 10/5/22 06:38, Bruno Larsen via Gdb-patches wrote: >>> Currently, when using GDB to do reverse debugging, if we try to use the >>> command "reverse next" to skip a recursive function, instead of skipping >>> all of the recursive calls and stopping in the previous line, we stop at >>> the second to last recursive call, and need to manually step backwards >>> until we leave the first call.  This is well documented in PR gdb/16678. >>> >>> This bug happens because when GDB notices that a reverse step has >>> entered into a function, GDB will add a step_resume_breakpoint at the >>> start of the function, then single step out of the prologue once that >>> breakpoint is hit.  The problem was happening because GDB wouldn't give >>> that step_resume_breakpoint a frame-id, so the first time the breakpoint >>> was hit, the inferior would be stopped.  This is fixed by giving the >>> current frame-id to the breakpoint. >>> >>> This commit also changes gdb.reverse/step-reverse.c to contain a >>> recursive function and attempt to both, skip it altogether, and to skip >>> the second call from inside the first call, as this setup broke a >>> previous version of the patch. >>> --- >>>   gdb/infrun.c                                |  2 +- >>>   gdb/testsuite/gdb.reverse/step-precsave.exp |  6 ++- >>>   gdb/testsuite/gdb.reverse/step-reverse.c    | 19 ++++++- >>>   gdb/testsuite/gdb.reverse/step-reverse.exp  | 55 +++++++++++++++++++-- >>>   4 files changed, 74 insertions(+), 8 deletions(-) >> Hi Bruno, >> >> I see these failures since this commit: >> >>      $ make check TESTS="gdb.reverse/step-reverse.exp" RUNTESTFLAGS="--target_board=native-gdbserver" >>      FAIL: gdb.reverse/step-reverse.exp: reverse next over recursion again >>      FAIL: gdb.reverse/step-reverse.exp: enter recursive function >>      FAIL: gdb.reverse/step-reverse.exp: step over recursion inside the recursion > Hi Simon, > > Sorry about the delay in responding to this, took me a while to track it down. > > This was actually a latent bug, not a regression. If you try to run gdb.reverse/step-reverse in the native-gdbserver setup manually, then run the following commands: > > (gdb) tbreak main > (gdb) record > (gdb) until 61 > (gdb) rn 2 > (gdb) n > > You'll see the same failures. After the final next we should be stopped at line 58, and we end up on line 61 instead. > > This happens because when recording the instruction call, GDB doesn't seem to save the stack change, only registers, so when reconstructing the state we aren't aware that the return address changes. This makes it so when setting the breakpoint at the return address, we set it to the return of the second callee return, instead of the first callee in this case (or recursive_callee in the case you found). > > I hope this explanation made sense... 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? Thanks, Simon