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 35B123858C53 for ; Tue, 28 Mar 2023 15:38:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 35B123858C53 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.146] (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) (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 9DFEE1E0D3; Tue, 28 Mar 2023 11:38:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1680017898; bh=sHyEZdLpshGMn4FFUuIRnLv8y3r66AU1fWd+F2a6Xeo=; h=Date:Subject:To:References:From:In-Reply-To:From; b=E+zYKkSbFnR2WigSyzcLKact9Y4rHqoUkJ2HEAio0G0khyei8aU6tGVFNHMcD4k4I W8QIL7T0XfPRljyG/AuOnqSTHrAGGyRkxivfYZlGWFTRFaa5q0UD/IQZMGrKM7c5fA JIoE/t0B7UkgTPDDbq6AYS7CDSQdCDAllZtuD7UM= Message-ID: <90c98190-f8eb-1d64-43ce-8bab67d5caef@simark.ca> Date: Tue, 28 Mar 2023 11:38:18 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH 2/2 ] PowerPC: fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp Content-Language: fr To: Carl Love , Tom de Vries , Ulrich Weigand , "gdb-patches@sourceware.org" , Bruno Larsen , "pedro@palves.net" References: <7a494157-494f-6adf-d533-bf373b0f054f@redhat.com> <71aa635593df0677811afb85409aa190bcfa4f6a.camel@us.ibm.com> <15864a6b87b25c93e99a28149f23138267735f2a.camel@us.ibm.com> <041f62e9f26fd4a536bc90c34f072985582e6237.camel@de.ibm.com> <46c2c756475ba5923d7eed97996632a08285dd42.camel@us.ibm.com> <65861786-069e-53a1-ca17-a525b6629c95@suse.de> <5be0c849abeef84d34a6ff255fb2705ca5dcb035.camel@us.ibm.com> <5e60a837-b21c-011f-c94e-e8bbf7645c5d@simark.ca> <7639de48695d52a806627b0a91979ad2e5fd9b42.camel@us.ibm.com> <9cf51eb9-c731-6f42-ab2b-a37048f25d12@simark.ca> <60c362e6dadd05754907af5f10e6f3c0423e1901.camel@us.ibm.com> <2a1d55cb-118b-d942-b315-a5f2348894f5@simark.ca> <0ab7af40f2f8d1edbceea851c37282a03c830567.camel@us.ibm.com> From: Simon Marchi In-Reply-To: <0ab7af40f2f8d1edbceea851c37282a03c830567.camel@us.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_MANYTO,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 3/28/23 11:17, Carl Love wrote: > Simon: > > On Mon, 2023-03-27 at 21:19 -0400, Simon Marchi wrote: >> To confirm the theory, I added a: >> >> gdb_test "set range-stepping off" >> >> somewhere near the beginning of your test, and it makes the test pass >> with native-gdbserver. >> >> If we want recording to work the same with process targets using >> range-stepping and those that don't, maybe GDB should avoid using >> range-stepping when the record-full target is in effect? > > We could just update the test to include gdb_test "set range-stepping > off" with a brief explanation of the issue. This would have a minimal > impact on performance of this test and no performance degradation for > any other tests. It sounds like this would fix the issue for just this > test. > > It sounds like disabling range-stepping when record-full is enabled > would be the more general fix for the issue. Not sure if there are > other tests where this issue occurs. Doing the more general fix would > probably have some performance impact on the other tests that need to > use record-full. I can't really say how much of an impact it would be. It depends on what the goal is. In general, we try to minimize the differences in behavior when debugging native vs debugging remote. So, if we say that it's a bug that the record-full target doesn't see all the intermediary steps, then putting "set range-stepping off" in that test would just be papering over the bug. I think the correct thing to do would be to fix GDB. And yes there will be a performance impact when using remote debugging + record-full, but if that's what's needed to get correct behavior... Some ideas to implement this: - Add a target method supports_range_stepping, record-full would implement it and return false. The default would be true. - record-full's resume method could clean the resumed thread's may_range_step flag. I'm open to other ideas. Note that we don't want to disable range stepping for other record implementations (only btrace, currently), I don't think that one is affected by the problem (the hardware should record all intermediary steps in any case). Simon