Break into an emulator's debugger from an opcode

Struggling with Fuse or trying to find an emulator with a specific feature. Ask your questions here.
AndyC
Dizzy
Posts: 64
Joined: Mon Nov 13, 2017 5:12 am

Re: Break into an emulator's debugger from an opcode

Post by AndyC » Mon Dec 25, 2017 7:06 pm

The biggest problem is that any "unused" instruction you could try to appropriate is going to be a multi-byte sequence and that makes it difficult to safely inject into code without potentially changing the meaning of subsequent bytes, since you can't then replace a one byte instruction with a breakpoint.
0 x

User avatar
RMartins
Microbot
Posts: 164
Joined: Thu Nov 16, 2017 3:26 pm

Re: Break into an emulator's debugger from an opcode

Post by RMartins » Mon Dec 25, 2017 8:35 pm

bob_fossil wrote:
Mon Dec 25, 2017 4:27 pm
... we are talking about emulators here not fully blown C IDEs.

From my perspective I don't see how this is easier for me or less work for an emulator developer to provide me with the option to treat a specific opcode sequence as a command to break into the debugger than it would be to have to load in and parse generated compiler symbol files to achieve the same thing?
I believe you need a bit of the 80's spirit, and not expect to have everything, because as you say, these are emulators and not IDEs. :D

The benefit here, is when the emulators accept the symbol as a variable, or a variable + something.
- breakpoint at MY_FUNCTION
- breakpoint at MY_LABEL (you can defined LABELS anywhere in your code, including before the line you want to test or pause execution at)

Another real advantage, is that you do not need to stop on that line every single time, when you have a defined breakpoint, you can disabled it, during debugging, or use breakpoint counting (in some emulators), where you only stop at the Nth time you go over it, or even better, when a specific condition is true.
However, if you have a specific opcode instruction in your code to call debugger and interrupt execution, it will force you to stop everytime it executes that instruction.

If the emulator allows it, and supports code rewrite by user, you can overwrite the opcode with NOPs, but that is not super simple either, since it requires some manual input again.

An emulator that supports symbols, typically will also support using those symbols directly, in breakpoints, setting values or similar inputs.
Note however, that most do not save the setting by name, so that it will stick on your next launch of the Emulator.

Alternatively (I use this trick a lot), I keep my emulator open, with breakpoints defined, during my entire debugging session, which keeps all breakpoints in the correct spot (given the correct care). I then open, re-open or drag & drop the new compiled app, into the running emulator.

If you know which code you are changing while debugging, the function location will be kept in the exact same spot, as long, as you do not alter any other code that comes before it in memory.
0 x

User avatar
bob_fossil
Dizzy
Posts: 63
Joined: Mon Nov 13, 2017 6:09 pm

Re: Break into an emulator's debugger from an opcode

Post by bob_fossil » Mon Dec 25, 2017 10:49 pm

As it's space year 2017, it seems silly doing things with an 80s spirit especially when I'm cross compiling code on a laptop to run inside an emulator. So I've been terribly modern and downloaded source code for a Spectrum emulator that runs on Linux (fbzx) and done some Christmas bodging powered along with some trifle and some cider and got that break into a debug screen when it hits an ED 00 - this doesn't need to be injected as I can just assemble this into my code with a defb sequence when I compile the code. This shows all the Z80 registers and halts execution so I can see what's going on when something goes wrong or when something isn't working as expected. It's not Visual Studio but it's a start.
0 x

AndyC
Dizzy
Posts: 64
Joined: Mon Nov 13, 2017 5:12 am

Re: Break into an emulator's debugger from an opcode

Post by AndyC » Mon Dec 25, 2017 11:43 pm

Sure, it's not so much that it can't be done that way (which is akin to how old fashion trapped loaders worked), it's just that it's not a very general solution and something emulator authors are unlikely to adopt. The problem is that, as far as the emulator is concerned, the instruction still has to "execute" - T-states will be counted, the R register updated, timing of other parts of the system advanced. So whilst it might seem ok for very primitive source level debugging, it soon starts to fall down if you want to integrate things like Nirvana multicolor or use any kinds of timing loop.

Moving breakpoint generation out of the critical path and using the map files provided by z88dk would potentially be a lot more powerful, not only because it prevents debugging from upsetting Z80 state but also because things like source-level single stepping should be possible too.
0 x

Post Reply