#119 Conditional breakpoints

[SD Snatcher]

It would be a very usefull for MSX developers if
openmsx could have conditional breakpoints, not just
the static breakpoints we have now.

Something like:

debug break setcondition CPUwrite io 0xC0 0x28 (this
would break the emulation if 0x28 is written to the
MSX-Audio select-register port.)

debug break setcondition CPUread PSG\ regs 1 0xF0

debug break setcondition eval VDP\ regs 2 > 0x20

Any of the debuggables could have an setcondition
CPUread, CPUwrite operations, or when the "eval"
expression is true.

Something like this would speed up a lot our
MSX-software development.

Best Regards,
FRS

[Maarten ter Huurne]

Logged In: YES
user_id=358343

I often do something similar by adding
MSXCPU::instance().doBreak(); inside an "if"
statement the code. Of course most users will not
like recompiling openMSX to add a conditional
breakpoint, so being able to do this in TCL would be
a lot better.

I wonder if we should make conditional breakpoints
(like you described above) or whether we should
make conditional events that can trigger anything,
including a breakpoint. My feeling is that the latter is
more flexible.

Example:
after output 0xC0 0x28 [ debug break ]
after output 0xC0 0x28 [ puts "port written" ]

The trick would be to include a filter in the event itself
that is specific enough that the TCL code is not
evaluated too often. For example, calling the TCL
code on every I/O write is probably very slow
(although we should test this: I don't know exactly
how fast or slow TCL execution is), calling it on every
I/O write to port 0xC0 reduces the number of calls a
lot and calling it only when value 0x28 is written to
that port reduces it to a probably very small number
of events.

Note that a breakpoint will always suspend execution
immediately after the event has occurred. So it is too
late to display the old value of the MSX-Audio register,
for example. In the current architecture of openMSX it
is not possible to break before the state change
happens. We could make that possible by turning I/O
into events, but I'm not sure of the overhead that
would cause.

[SD Snatcher]

Logged In: YES
user_id=130840

> Note that a breakpoint will always suspend execution
> immediately after the event has occurred. So it is too
> late to display the old value of the MSX-Audio register,
> for example. In the current architecture of openMSX it
> is not possible to break before the state change
> happens.

That would not be much of a problem, since when debugging
we generally need to know the context that generated an
incorrect behaviour. The old value is not so important then.
And the old value would be easy to get if something like this
could be done:

after output 0xC0 [ puts "port 0xC0 written $value" ]

About the syntax, I sugested mine trying to mantain the
coesion with the debuggables names, which should be easier
to remember and probably to implement.

Of course your sintax is very powerfull too, so maybe a mix of
the two propositions should be the best, like:

settrigger eval PSG\ regs[2] > 0x20 [ debug break ]

or

settrigger eval VDP\ regs[2] AND 0x10 [ debug break ]

or even:

settrigger eval ioport[0xC0] = 0x28 [ puts "port written" ]

This is flexible both on the "conditional portion" and
the "execute portion". :)

[Wouter Vermaelen]

Logged In: YES
user_id=356949

Conditional breakpoints are implemented:

debug set_bp <address> [ <expression> ]

For performace reasons we require an address (evaluating the
expression after every instruction would be too slow).

The PC = addr the expression is evaluated, when the result
is true openmsx will break.

There are no conditional breakpoints yet on memory/IO
read/writes (such things are usually called watchpoints
btw). Is this is required then please create a new RFE for it.