-
Notifications
You must be signed in to change notification settings - Fork 19
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
Debugging: step over behavior #80
Comments
Hi! Glad you find them useful.
Agreed it would be nice to be able to skip reps and loops and such. Step over currently only has an effect on calls but if the current instruction is not a call I could just have it skip to the next decoded address.
So step over is a bit of a hack at the moment. The main issue is that there's no guarantee that you can step over anything. Internally I am saving the return address on a call, but we may not end up back at that address for various reasons, interrupts being one. So there is a timeout - if we don't return after a certain number of instructions I just break after the timeout elapses. This ends up plopping you in some random place. Without the timeout, you might just step over something and see the emulator just keep running again forever after. I wasn't sure which method is better in the end. Do you know how other emulators/debuggers handle this? |
I just checked debugging Java in IntelliJ IDEA as a random example. When you hit "step over" on a method and the method does not return (for example, there could just be an infinite loop), the program just keeps running and does not return to the debugger (unless another breakpoint is hit). I think, this is simple and reasonable behavior for a debugger. If the function call / method call / .. never returns, you just have to start over again and use "step into" instead (or change breakpoints accordingly). |
Hi @krangerich, I have implemented the new step-over behavior, on track for 0.2.1. I added step_over_target to REP string operations so they can be skipped. It's a valid question as to why regular stepping doesn't work over REP string operations. MartyPC handles them a bit specially - on a real 8088 they are indeed a single atomic instruction that self-terminate on interrupts. However this could mean that a single 'step' in the debugger could execute 1 million+ cycles. This robs us of the use of our debug windows to examine peripheral and video state during a string operation - if we step-per-iteration instead, we can literally watch the bytes get copied into memory, if we are doing a move into MMIO area we can see realtime device changes. I think step-over REP is a good compromise. There is another tweak I would like to do, and that is to keep the presently running string operation at the top of the debug window. Right now the only way to tell you are in one after the first iteration is to look into the cpu history, which get spammed with rep xxx entries. There is another similar situation with HALT. Both of these technically advance CS:IP so the disassembler will skip them after they are first executed. Instead of feeding ip to the disassembler I think I will have an disassembly_ip() method that will rewind IP backwards for REP string and HLT instructions so they remain at the top of the disassembly view until they are resolved. I'd like to add step-past as well; this would be handy for skipping past the end of various loops. I should probably disable it if the current instruction is an unconditional jump. Step-out or step-return is also possible, but complicated by the ridiculous difficulty of tracking the 8088's call stack. |
Hey, thanks, thats good to hear! |
All the debugging capabilities are awesome!
But I have some additional suggestions regarding the "step over" button in the "CPU Control" window:
The text was updated successfully, but these errors were encountered: