public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Bruno Larsen <blarsen@redhat.com>
To: Christian Biesinger <cbiesinger@google.com>
Cc: Reuben Thomas via Gdb <gdb@sourceware.org>
Subject: Re: [RFC] Change displayed line when execution direction is reversed
Date: Wed, 15 Jun 2022 09:49:58 -0300	[thread overview]
Message-ID: <da25692d-25d7-319d-bc71-c912f25837c0@redhat.com> (raw)
In-Reply-To: <CAPTJ0XG6PVz1NR+cKr3m+Df9itoa5ZXXweXT08j+Nny6rZYXRg@mail.gmail.com>

You are correct. I would only want to print differently when the user explicitly changes the direction. Otherwise it would get confusing very quickly, as you mentioned.

Cheers!
Bruno Larsen

On 6/15/22 09:47, Christian Biesinger wrote:
> Sorry, just to clarify, you are not suggesting a change when using
> "reverse-next" without "set exec-direction reverse"?
> 
> Christian
> 
> On Wed, Jun 15, 2022 at 8:39 AM Bruno Larsen <blarsen@redhat.com> wrote:
>>
>> 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 <gdb@sourceware.org> 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
>>>>
>>>
>>
> 


  reply	other threads:[~2022-06-15 12:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-15 12:25 Bruno Larsen
2022-06-15 12:34 ` Christian Biesinger
2022-06-15 12:39   ` Bruno Larsen
2022-06-15 12:47     ` Christian Biesinger
2022-06-15 12:49       ` Bruno Larsen [this message]
2022-06-15 12:57         ` Christian Biesinger
2022-06-17 12:07 ` Pedro Alves
2022-06-17 13:03   ` Bruno Larsen
2022-06-17 13:44     ` Pedro Alves
2022-06-17 19:35       ` Bruno Larsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=da25692d-25d7-319d-bc71-c912f25837c0@redhat.com \
    --to=blarsen@redhat.com \
    --cc=cbiesinger@google.com \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).