Data breakpoints are useful when you want to know if a specific thing changes, but fast watch window is much better in most circumstances so you can just see _everything_ that changes as you step, without having to guess in advance.
-
-
This Tweet is unavailable.
-
Replying to @UnrealDrMcCoy @RyanAlban1 and
But even if data breakpoints are your thing, Remedy's data breakpoints are _fifteen times faster_ than Visual Studios, so, I could have done that as a demo of how bad Visual Studio sucks as well :)
2 replies 0 retweets 1 like -
Replying to @cmuratori @UnrealDrMcCoy and
Does Remedy let us specify arbitrary data sizes for the thing to watch? That's one feature I think is missing from VS's debugger and I'm not sure why they don't allow that. Would be useful to break on anything in a given structure changing.
1 reply 0 retweets 0 likes -
Replying to @RyanAlban1 @UnrealDrMcCoy and
I don't think RemedyBG has that feature yet, because it supports _hardware_ data breakpoints (which are extremely fast), not software data breakpoints (which would be very slow). Hardware breakpoints on x64 only support 8 bytes, IIRC (I may not remember correctly though).
1 reply 0 retweets 1 like -
Replying to @cmuratori @RyanAlban1 and
In order to support _more_ than 8 bytes, you have to do a bunch of page locking and diffing, which would be very very slow compared to hardware breakpoints which are effectively free.
1 reply 0 retweets 0 likes -
Replying to @cmuratori @UnrealDrMcCoy and
I figured it was something at the hardware or OS level keeping VS from doing it, as well. Are there perf concerns with the number of hardware breakpoints set? Eg. if I have a structure that's 16 bytes, I'd set two hardware breakpoints and then have the IDE present it as one.
1 reply 0 retweets 0 likes -
Replying to @RyanAlban1 @UnrealDrMcCoy and
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.
1 reply 0 retweets 0 likes -
Replying to @cmuratori @RyanAlban1 and
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 :)
1 reply 0 retweets 1 like -
Replying to @cmuratori @RyanAlban1 and
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.
1 reply 0 retweets 0 likes
So it's really not the kind of thing you want the IDE to make promises about that are fake. The programmer needs to know what they're doing and understand the limitations or they could misinterpret a run where the breakpoint did not hit.
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.