Forums

I'd like to set a breakpoint on an area of ROM to find out whether it contains any data, or just code. Thus I'd like to break only on reads from the area, not when code is executed from there.

I tried b r 1234..5678, but this caused execution to stop each time code in the area was executed, since the CPU is reading opcodes from the area.

In other words, b r ... seems to be behaving the same as b rx .... Is this intended, or have I not set my breakpoint correctly?

Yes you hit a problem here.

Currently what does the implementation does:

- X breakpoints are only triggered on the first byte of the instruction
- R breakpoints are triggered on all bytes of the instructions and anything the instruction may be reading from.

The problem is that currently X breakpoints by design are triggered *before* the instruction is executed, so the same approach used for data can't work.

//

Possible solution in two points.

If you want to fix that X only apply to the first bytes:

- We need a function that tells us instruction length from a given location.
The function "Debugger_Hook(Z80 *R)" in debugger.c does the check with PC and this has to be extended to do the check for the complete size of the current opcode.

Also the call to Debugger_Hook() itself is checking is Debugger_CPU_Exec_Traps[R->PC.W] is not NULL as an optimization. Removing that and letting Debugger_Hook compute the instruction size and check for all everytime may be overkill. I think a good-enough workaround would be for the check to be extended to say, 4-bytes or anything we consider as a reasonable max instruction size (note that in theory CB/ED prefixes can be concatened to produce very long instruction size but in practice nobody does that).

If you want to disable the fact that R alias X :

- MEKA there is only one call "RdZ80()" from the CPU emulator point of view, it should be split into, say, RdZ80Data() / RdZ80Exec(). The later would actually do nothing (no special hook) because the X hooks are performed in the instruction fetching loop.

Note that they are function pointers right now which is quite terrible for performance (the opaque calls breaks most optimizations) and splitting them in two would make things in theory worse, but the low cost of Z80 emulation and the purpose of MEKA now makes it a totally acceptable solution.

That's mostly notes for myself so I may give it a look sometimes.

Author	Message
RetroSpark Joined: 08 Dec 2005 Posts: 488 Location: Melbourne, Australia	Breakpoints: Instruction fetch counts as "read" Posted: Sat Aug 14, 2010 1:22 am
	I'd like to set a breakpoint on an area of ROM to find out whether it contains any data, or just code. Thus I'd like to break only on reads from the area, not when code is executed from there. I tried b r 1234..5678, but this caused execution to stop each time code in the area was executed, since the CPU is reading opcodes from the area. In other words, b r ... seems to be behaving the same as b rx .... Is this intended, or have I not set my breakpoint correctly?

Bock Site Admin Joined: 08 Jul 2001 Posts: 8648 Location: Paris, France	Posted: Sun Aug 15, 2010 4:31 am
	Yes you hit a problem here. Currently what does the implementation does: - X breakpoints are only triggered on the first byte of the instruction - R breakpoints are triggered on all bytes of the instructions and anything the instruction may be reading from. The problem is that currently X breakpoints by design are triggered before the instruction is executed, so the same approach used for data can't work. // Possible solution in two points. If you want to fix that X only apply to the first bytes: - We need a function that tells us instruction length from a given location. The function "Debugger_Hook(Z80 *R)" in debugger.c does the check with PC and this has to be extended to do the check for the complete size of the current opcode. Also the call to Debugger_Hook() itself is checking is Debugger_CPU_Exec_Traps[R->PC.W] is not NULL as an optimization. Removing that and letting Debugger_Hook compute the instruction size and check for all everytime may be overkill. I think a good-enough workaround would be for the check to be extended to say, 4-bytes or anything we consider as a reasonable max instruction size (note that in theory CB/ED prefixes can be concatened to produce very long instruction size but in practice nobody does that). If you want to disable the fact that R alias X : - MEKA there is only one call "RdZ80()" from the CPU emulator point of view, it should be split into, say, RdZ80Data() / RdZ80Exec(). The later would actually do nothing (no special hook) because the X hooks are performed in the instruction fetching loop. Note that they are function pointers right now which is quite terrible for performance (the opaque calls breaks most optimizations) and splitting them in two would make things in theory worse, but the low cost of Z80 emulation and the purpose of MEKA now makes it a totally acceptable solution. That's mostly notes for myself so I may give it a look sometimes.

Forums

View topic - Breakpoints: Instruction fetch counts as "read"