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 76D63385AC2D for ; Wed, 2 Nov 2022 17:46:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 76D63385AC2D 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.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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1667411201; bh=XalnJk3EuihFgwwPw/ZPoekLt0QhaysyuJdOwZT/J+8=; h=Date:Subject:To:References:From:In-Reply-To:From; b=wJpULawPaJDiUqOX7UG8mexKpsiBUZoyMlx24G4Q8JFCMl40ILbgcx52Qk51QckRt gy/Val1POZnsJ27kZwGoTklnxldcrPlb8uy6WbnlcpwuE6cPUmp/Bb0cVWmd8DJPnr bX79rH8QUgyExtsSN588H1JKG4V2Iem1QhMPfPJc= 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> From: Simon Marchi In-Reply-To: <4cc13e71-aa24-b66b-f8bc-1bb9b7e17b59@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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/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