From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1667408637; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bibaxx8Or69pZ9zEzTetehwgI80tmxfjQhNjJDl5L60=; b=W6m3kGAQblg05Tu6GpvQJrqksd1iLnamhlwMJ1Cy9MIISQSNACYJrbz0WhheMxbftIkxOf cvG0SsdbvMB1msb7nkc6MGj5llv0X2IerJiqaZ0j7U702BeuwNL34nX7gt8XLiS+FEvo98 t6NIw+EbgT8gjLRdtkHQh7zt+8Sbmms= 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> From: Bruno Larsen 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-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no 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 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 >