I've used them a few times to help track down memory corruption issues. You can get the exact place and instant where your variable is being stomped by the errant code!
There is not a "number of hardware breakpoints set", really - you only get 4, period, IIRC. So it's not the kind of thing the IDE can abstract, for the most part, because there are so few. If they added dramatically more in some future chip, maybe it would make sense.
-
-
It's specific enough and limited enough that I think the debugger should just present it as it is (as four hardware breakpoints that can be 1, 2, 4, or 8 bytes each) and if the programmer doesn't understand that, they probably shouldn't be using them :)
-
I want to say that it also doesn't handle rep instructions... I could be wrong about that, but I _believe_ it is not "any time this address changes". I think it's more like "any time an instruction _specifically_ mentions this address". But again, I could be misremembering.
- Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.