From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ue6rDBjTqWKdWAIAWB0awg (envelope-from ) for ; Wed, 15 Jun 2022 08:39:52 -0400 Received: by simark.ca (Postfix, from userid 112) id 237DE1E224; Wed, 15 Jun 2022 08:39:52 -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=LvLfx+4h; 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=-4.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,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 BD0A61E15D for ; Wed, 15 Jun 2022 08:39:51 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 218073838647 for ; Wed, 15 Jun 2022 12:39:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 218073838647 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1655296791; bh=YLpW82amVYencelB8lxQ1Z5mQ/94NmtOOmsydYSNiSQ=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=LvLfx+4hjQlgQ02Jt6eH2mf3z6Fr1hpYj/0SZmwcAGxP2VQi6i5XY+kYl1QIUDnmy hNzenLUcOWpw5lweYc/DWRchcVj7hCSDKJOxHFM6ERt3GJmkNzs0Tpgmcop60Om2SK 0Umi5Lcy/EW1nNNcS3P4fwpsgZ6x/mM24zr+GQ+M= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id C3ED73857371 for ; Wed, 15 Jun 2022 12:39:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C3ED73857371 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-424-2sbdq6d-P4eKIGbVhgRmng-1; Wed, 15 Jun 2022 08:39:16 -0400 X-MC-Unique: 2sbdq6d-P4eKIGbVhgRmng-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id BB771101AA48; Wed, 15 Jun 2022 12:39:15 +0000 (UTC) Received: from [10.97.116.32] (ovpn-116-32.gru2.redhat.com [10.97.116.32]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 15A8640CFD0A; Wed, 15 Jun 2022 12:39:14 +0000 (UTC) Message-ID: <4ed767fb-f9d6-7dbd-47ce-1691a0a4ee38@redhat.com> Date: Wed, 15 Jun 2022 09:39:12 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [RFC] Change displayed line when execution direction is reversed To: Christian Biesinger References: <040e723a-1f8b-3fb2-a076-85664243513f@redhat.com> In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.11.54.1 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@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Bruno Larsen via Gdb Reply-To: Bruno Larsen Cc: Reuben Thomas via Gdb Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" It would only happen if the user explicitly used the command `set exec-direction reverse`. If the previous line was printed right after this command is run, I imagine the user would understand what is going on through context. That said, I'm open to suggestions on other messages or documentations of the feature to avoid confusion. Cheers! Bruno Larsen On 6/15/22 09:34, Christian Biesinger wrote: > My personal opinion: > In general, the state of the program when gdb is stopped is the state > at the start of the displayed line (I concede that it gets more > complicated when "step"ping) > This change would make it so the state is the state at the end of the > displayed line. > > I think that could be confusing? Perhaps could be mitigated by > printing a message explaining that in some way. > > Christian > > On Wed, Jun 15, 2022 at 8:26 AM Bruno Larsen via Gdb wrote: >> >> Hello all, >> >> I was doing some reverse debugging and noticed that setting the execution direction to reverse does not change how GDB displays lines. The problem with this is that the user doesn't see what will be executed if a step is taken, which makes the user experience quite annoying. How would the community feel if GDB printed the previous line, instead of current line, when the execution direction is reversed? >> >> Sorry if this is the wrong list. It didn't feel like a bug, and I don't have a patch yet, so this felt like the best place to send. >> -- >> Cheers! >> Bruno Larsen >> >