Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't jump to source after commands that don't progress the program #214

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

Charlie-83
Copy link

Currently (using gdb), typing a command like p foo will cause the program to jump to the source even thought the program hasn't progressed so it will jump to the same place each time. This is annoying when you want to print out a series of variable and you keep being taken out of the gdb terminal.

This PR stops this occurring by recording the previous filename + line we jumped to and only jumping if we are jumping somewhere else.

I have only implemented this for GDB (since it'' the only debugger I use). If there is interest in this PR, I can implement for the others.

@sakhnik
Copy link
Owner

sakhnik commented Jan 12, 2025

Hi! Thanks for your interest. The change breaks some use cases. Specifically, when :Gdb run is executed after program exit. Could you reset the last known position when the program exits or restarts?

@Charlie-83
Copy link
Author

I have fixed two cases.

  1. The case you mentioned where you hit some breakpoint and then rerun the program and hit the same breakpoint
  2. The breakpoint is in something like a loop so, after issuing continue you hit the same breakpoint again

@sakhnik
Copy link
Owner

sakhnik commented Jan 17, 2025

I wonder why I can't reproduce the bug. Could you please record a small demo maybe in asciinema?

@Charlie-83
Copy link
Author

What bug do you mean?

@sakhnik
Copy link
Owner

sakhnik commented Jan 17, 2025

I didn't notice any unwanted jumps. Neither can I reproduce #213.

@Charlie-83
Copy link
Author

https://asciinema.org/a/c7EpvcsNemBZOsMlBUptpxwRG

This is the behavior without this PR but with my patch for #213

#213 and this PR are separate. This PR is a feature while I think #213 is a bug. I haven't had time to look into #213 to find a reproducible case but I will get round to it soon. I will add an asciinema to it now though

@sakhnik
Copy link
Owner

sakhnik commented Jan 17, 2025

Oh, right, I can reproduce this behaviour now, thanks!
I see the Windows test failed. I'll look at it over the weekend.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants