openMSX "software" breakpoint

Enlighted (4155)

27-09-2019, 22:48

Hi, all, is there any (invalid) opcode sequence that triggers a breakpoint in openMSX debugger ? As in example:

ld a, 23
db invalidopcode, invalidopcode
ld c,2

my wish is that the second code line triggers a breakpoint like if i have set via openMSX debugger command at a specified address, without needing to know the address every time i build the executable

thx. in advance

Por Manuel

Ascended (19678)

27-09-2019, 23:44

This is not possible exactly, but you can do something similar: make an OUT instruction to an empty port and set an I/O breakpoint on that. This gives pretty much the same effect.

Por akumajo

Resident (43)

28-09-2019, 14:41

Maybe it would be possible to set up a principle as in BlueMsx?

http://www.msxblue.com/manual/debugger_c.htm

Por Grauw

Ascended (10820)

28-09-2019, 16:15

This is easy to do with openMSX breakpoints and watchpoints, e.g. in my projects I’ve set it up so that a read from I/O port 2EH triggers a breakpoint:

debug set_watchpoint read_io 0x2E

The debug device can be used to log debug information.

Por Manuel

Ascended (19678)

28-09-2019, 17:30

akumajo: can you explain what that principle offers extra?

Por akumajo

Resident (43)

28-09-2019, 18:30

Manuel wrote:

akumajo: can you explain what that principle offers extra?

The breakpoint does not need to be set in the debugger, the sequence of instructions allows, depending on the case, to :

- Set a program counter breakpoint:

ld b,b
jr $+2

(The breakpoint will be set after jr $+2)

- Set an address only breakpoint:

ld b,b
jr $+4
dw address

(The breakpoint will be set on the specified address)

- Set a debug string :

ld d,d
jr $+2+length
db string

The string will be output to the Trace Logger plugin.

AsMSX generates these codes automatically with directives :

.BREAK [X] / .BREAKPOINT [X]

DEBUG "text"

Por Manuel

Ascended (19678)

28-09-2019, 18:55

The problem with such 'invasive' way of debugging is that it enabling/disabling these statements affect the timing of your program... That's probably also why Grauw moved to non-invasive profiling.

What about loading a symbol file and put breakpoints based on symbol instead?

Por akumajo

Resident (43)

28-09-2019, 19:17

It's just two different approaches to debugging, so for a quick test it's easier to put the breakpoint directly into the code without worrying about the symbol file and the breakpoint position. Most of the time, at the time of debugging we do not need the speed of the program ... I just wanted to talk about it because it exists and some people use it with AsMSX and BlueMSX.

Por Grauw

Ascended (10820)

28-09-2019, 20:30

I use both approaches, for the profiler script it made sense to hook them in externally to improve the accuracy and not affect timing of things like line splits negatively. But I did need to make a TCL script to integrate it with the symbol files generated by my assembler, so it requires a bit more set-up in your programming environment.

The watchpoint approach is easier to use though and I also still frequently use it for debugging. It is also easier to make it only trigger conditionally by some expression evaluated in assembly (or C). Whenever an exception triggers in my program, it breaks the emulator in the exception handler with an in a,(2eh), and I step back a few instructions to quickly find the cause of the problem.

This is perfectly and easily possible in openMSX already, so there’s no need to mimic those other emulators and give special meaning to one of the Z80 instructions. I think the openMSX approach is cleaner, and also more powerful, e.g. if you have a more complicated case to debug you could treat the breakpoint differently based on parameters in registers like log a specific message, or keep a count of occurrences, or only break if the VDP is in a certain state, or make a savestate and continue running, or even execute an arbitrary string in MSX memory as a TCL command, etc.

Por wouter_

Hero (535)

29-09-2019, 10:36

akumajo wrote:

Maybe it would be possible to set up a principle as in BlueMsx?

http://www.msxblue.com/manual/debugger_c.htm

Hehe, this could also be abused to block your MSX program from being debugged in blueMSX: in a loop set a breakpoint on every address, have fun debugging like that ;-)
I checked the blueMSX source code, there currently doesn't seem to be a way to disable this feature :-(

Por akumajo

Resident (43)

29-09-2019, 10:38

Sometimes something simple is more powerful, the way you debug is interesting and you have to get there, but what is asked in this topic is a simple principle of introducing a breakpoint by opcode.

Quote:

is there any (invalid) opcode sequence that triggers a breakpoint in openMSX debugger

So we understand that this is not currently possible with the openMSX debugger and that this solution will not be implemented to not "mimic" other emulators (in fact it is the debugger, not the emulator, that detects this opcode) but the solution is to use a "in a,(2eh)" opcode.

I find it less convenient and as I said, it does not allow to use the debugging functions offered by ASMSX.