From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id mEyFExKjYmPHPxMAWB0awg (envelope-from ) for ; Wed, 02 Nov 2022 13:04:18 -0400 Received: by simark.ca (Postfix, from userid 112) id 4C8541E124; Wed, 2 Nov 2022 13:04:18 -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=HKK6tq4J; 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=unavailable 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 EFEF21E0D3 for ; Wed, 2 Nov 2022 13:04:17 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 76CA9385AC30 for ; Wed, 2 Nov 2022 17:04:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 76CA9385AC30 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1667408657; bh=bibaxx8Or69pZ9zEzTetehwgI80tmxfjQhNjJDl5L60=; 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=HKK6tq4JpHn/MHPTF3q0MyNZvf7uOrJT0g0i9ebrDFrI8kYt6OAnqfZuZkFJqS/Xi P3detlBpk/b8JT1/ts1sNzql/v9HS4YZ8VCY4pdMhX+juM6bQlxZHOYBkoO+ouZUju hD91HrMMAf72ByNoxCmglEDbwDZT5/mlPD6sOCuc= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id B582338582A6 for ; Wed, 2 Nov 2022 17:03:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B582338582A6 Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-653-ILbwCB4iOEqqueXMq5gG5w-1; Wed, 02 Nov 2022 13:03:56 -0400 X-MC-Unique: ILbwCB4iOEqqueXMq5gG5w-1 Received: by mail-qk1-f197.google.com with SMTP id u6-20020a05620a430600b006e47fa02576so15853170qko.22 for ; Wed, 02 Nov 2022 10:03:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=bibaxx8Or69pZ9zEzTetehwgI80tmxfjQhNjJDl5L60=; b=namZtlnCPpPQD7NXPJ0U1+4M9QEfBZaLziir6ssB6HrRKwK6e3Y+8HIm8NcMRhDcHp nMXuJfC+tJiX6bAUfNXlPtT61AdzI1tbGi9XZvfzUBPbD5lX75E7owC+dA3+mQY2vk2P KxzHec30IrenKdJEcJ7KKgXycLOr5JgNbkQj71/C32Tn4o/IEbsS8pjO0qw3/qFfF3Gp A9qh4ofTbV2ZiIdN7u0X0ZTMfV7vgz42IyCQ5Yd77rp5FCwiQHrNqtT4r9egEeRZcy+q qI6XlA3nmKj0lvafPmLQE4GuE6L0+209/EfAQvtZvd4VffgcvkGu88H69Da7MxyWvMRD S0Ww== X-Gm-Message-State: ACrzQf0ka3f62P7NoQEBHjK1bgSi/Qg7VDPp4o9fyHOPoJ3Cp8nMcDJm 9ZOlHwdZIifhw+bNiNAp4TvCKgbujTk/mfBF65kFrq4xFEjoqCJjC4hz/2XzLhDOanLslwwns89 x1BLEiUPfvZi7jYdabZL4hg== X-Received: by 2002:ac8:5a02:0:b0:39e:209e:7177 with SMTP id n2-20020ac85a02000000b0039e209e7177mr21000388qta.409.1667408635245; Wed, 02 Nov 2022 10:03:55 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4mLeM8p7PDBIvyy90LG2/EEIlNUfp2fFzZK5LTjc/wrVVO5A81uy1JE4rRGvncIc2lngHQgw== X-Received: by 2002:ac8:5a02:0:b0:39e:209e:7177 with SMTP id n2-20020ac85a02000000b0039e209e7177mr21000368qta.409.1667408634957; Wed, 02 Nov 2022 10:03:54 -0700 (PDT) Received: from [192.168.0.45] (ip-62-245-66-121.bb.vodafone.cz. [62.245.66.121]) by smtp.gmail.com with ESMTPSA id c5-20020ac81105000000b003a494b61e67sm6796074qtj.46.2022.11.02.10.03.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Nov 2022 10:03:54 -0700 (PDT) Message-ID: <4cc13e71-aa24-b66b-f8bc-1bb9b7e17b59@redhat.com> Date: Wed, 2 Nov 2022 18:03:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Subject: Re: [PATCH v4 2/2] gdb/reverse: Fix stepping over recursive functions To: Simon Marchi , gdb-patches@sourceware.org References: <20221005103832.3163424-1-blarsen@redhat.com> <20221005103832.3163424-3-blarsen@redhat.com> <95cc9197-e54a-f6ea-8092-d6d0063c58a3@simark.ca> In-Reply-To: <95cc9197-e54a-f6ea-8092-d6d0063c58a3@simark.ca> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed 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: Bruno Larsen via Gdb-patches Reply-To: Bruno Larsen Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" 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... Cheers, Bruno > > Simon >