From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id BfnQHrx7rGIL5QIAWB0awg (envelope-from ) for ; Fri, 17 Jun 2022 09:03:56 -0400 Received: by simark.ca (Postfix, from userid 112) id 691141E224; Fri, 17 Jun 2022 09:03:56 -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=umso+kO2; 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 C328E1E143 for ; Fri, 17 Jun 2022 09:03:55 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 111CC386F0CC for ; Fri, 17 Jun 2022 13:03:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 111CC386F0CC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1655471035; bh=S0rFAMm/EBufEClVqMbhFnAjKV/8HXmRUG9GTh+0t4k=; 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=umso+kO2SwyFkeAFj7XgkpA2RQQnnRs62oColfFSs0UMebgtgxJHbXZJiyDvtjRwe NWwWn4qVx3St2gLY0N9KDSCF6laxPsrAz5quSWpY3dzYptqBLUU55x+tZcpF47J8CS 3FpIhyZbraT/5cOIeE+ZfOM4S1Z1Tx6EwjfczekI= 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 DDC2A3856261 for ; Fri, 17 Jun 2022 13:03:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DDC2A3856261 Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-675-v6gAGPs-NRO-oqePZlR4Kg-1; Fri, 17 Jun 2022 09:03:26 -0400 X-MC-Unique: v6gAGPs-NRO-oqePZlR4Kg-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 D262B29AB418; Fri, 17 Jun 2022 13:03:25 +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 2A67B40149A6; Fri, 17 Jun 2022 13:03:24 +0000 (UTC) Message-ID: Date: Fri, 17 Jun 2022 10:03:22 -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: Pedro Alves , gdb@sourceware.org References: <040e723a-1f8b-3fb2-a076-85664243513f@redhat.com> <1e63f554-b24b-0bfb-e97d-d182ca6a41d2@palves.net> In-Reply-To: <1e63f554-b24b-0bfb-e97d-d182ca6a41d2@palves.net> 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 Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 6/17/22 09:07, Pedro Alves wrote: > On 2022-06-15 13:25, 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. > > How do you know which line that would be? E.g.: > > if (foo) > func (); > else > bar (); > qux = 0; // stopped here. > > Say you're stopped at the "stopped here" line, and flip execution direction to reverse. Which line would gdb show as next line? I'm not sure of the how yet, but the plan would be to show the correct line (in this case, if foo == true, show func (), otherwise show bar ()). My first plan would be to add a way to query which PC should be used to calculate the line, so regular targets just return the current PC and recorded targets can see the PC of the previous instruction, then use that to identify the source line. This system sounds easy enough in my head, but without any testing I can't say for certain that it works (and with the current knowledge, it'd take me some time to test it), so if you can think of problems this would have, or a better idea, I'm all ears! > > > Also, showing a different line would result in the current PC (p $pc, info registers) etc. printing an > address for a line totally unrelated to the line that GDB is displaying, no? Same for "break" with no > arguments, etc. Worse, what happens when you print variables? The block scope used is the one for the > current PC, while gdb would display a different source line as current line? Let me try and explain with an example GDB session. Say the program is: int main(){ int x = 2; x += 2; x *= x; x /= 2; return 0; } Currently, GDB does this: (gdb) start 2 int x = 2; (gdb) display x 1: x = 32767 (gdb) n 3 x += 2; 1: x = 2 (gdb) 4 x *= x; 1: x = 4 (gdb) 5 x /= 2; 1: x = 16 (gdb) 6 return 0; 1: x = 8 (gdb) set exec-direction reverse (gdb) n 5 x /= 2; 1: x = 16 (gdb) 4 x *= x; 1: x = 4 (gdb) 3 x += 2; 1: x = 2 As we move forward, we see what the inferior will do next, and we see the value of x at the start of the line. However, as soon as we move backwards, we are now seeing what we have just done, and the final result of having done it, i.e. the state at the start of the line. If my idea is implemented, the session would look like this (gdb) start 2 int x = 2; (gdb) display x 1: x = 32767 (gdb) n 3 x += 2; 1: x = 2 (gdb) 4 x *= x; 1: x = 4 (gdb) 5 x /= 2; 1: x = 16 (gdb) 6 return 0; 1: x = 8 (gdb) set exec-direction reverse 5 x /= 2; (gdb) n 4 x *= x; 1: x = 16 (gdb) 3 x += 2; 1: x = 4 (gdb) 2 int x = 2; 1: x = 2 Now, going forward works the same, but going backwards, I see what the inferior will undo next (which is the opposite operation than what is written), and I see the state of the inferior right before undoing the line. This would make the most difference when showing a function call (so I know I need to "step" instead of "next) or when I will lose state through an assignment operation. The break with no arguments can cause some confusion if the user changes execution direction often. To make things more clear, we could perhaps print Breakpoint 1 at 0x401186: file 16678.c, end of line 3. instead of printing Breakpoint 1 at 0x401186: file 16678.c, line 4. so that if the execution direction is reset to forward, the user isn't caught by surprise. > > I don't see off hand how this can work. Can you detail it? > One final detail, just to make sure you are aware, this change would only apply when the user explicitly uses "set exec-direction reverse". Nothing would change for "reverse-next" or similar. Does this make more sense? Cheers! Bruno Larsen