Simple breakpoint improvements [Imported Thread]

Idea Originally posted by Dave 20/04/2009

1) On the context menu that appears when a variable is right clicked, you should have “breakpoint on read of “, “breakpoint on write to “, and “breakpoint on access of ” (which is read or write). Currently, you have “Set breakpoint on “, but it only works for write access. If you want a breakpoint on a read then you have to manually enter the address and size of the variable using the edit dialog, which brings me to my next point…

2) When a breakpoint is invalid, the reason should be placed next to the breakpoint in the breakpoint window. Right now, to find out why a breakpoint is invalid, you have to find the breakpoint properties window, which is not always easy to find!

Comments

26/10/2011 Jonathan Elliott (Admin)

Read/write access breakpoints are already implemented--that is, a general data breakpoint is available.

26/10/2011 Dave Sudolcan

How about break on memory read/write accesses, so you can find out where a value is being changed? Even better, break on an expression such as when a memory location and some bit mask is true or false, to find out where bits are changing when you don't expect them to?

07/04/2010 Graham Cole

Other instruction fetch breakpoint options might include: Resume execution: the watch windows etc are updated and then execution automatically resumes. Resume if not executed: the debugger takes a peek at the condition codes of the instruction and the current CPU state and then automatically resumes if the instruction will not actually be executed. (However, always break on what is effectively a NOP instruction.) This will help make it possible to do useful debugging with higher degrees of optimisation enabled.