开发者

Why only breakpoints tied to lines, rather than some set of state?

开发者 https://www.devze.com 2023-01-31 10:42 出处:网络
Why is it that breakpoints are always tied to lines, and optionally to state? Why can\'t we have breakpoints that are tied solely to state or state changes, and not to lines? How does this relate to b

Why is it that breakpoints are always tied to lines, and optionally to state? Why can't we have breakpoints that are tied solely to state or state changes, and not to lines? How does this relate to breakpointing on a whole class?

We can typically suspend execut开发者_高级运维ion at an arbitrary point -- why can't we have our IDE's suspend execution when a certain state is hit, wherever the execution point is? How would we implement these breaks? (I assume that by the time the state change has triggered a suspension the code being debugged may have continued).

I started thinking about this recently, when I wondered if there might be a way of suspended execution when a certain file was accessed, and thought also about how my debugging process often splits into two components: targeted breakpointing and global searches based on hunches about the code is behaving.

Due diligence: related post here, at least.

addition: my particular immediate interest happens to be in c# on visual studio -- with Mark Wilkins' link below I managed to track down "data breakpoint" setting in visual studio, only enabled while debugging C++ native code.


It is possible to set breakpoints such that it stops in the debugger when a value at an address changes (data breakpoints). I believe that in GDB it is called a watchpoint. And in Visual Studio, you can set a data breakpoint as well (menu Debug \ new breakpoint).


"Data breakpoints" are often requested for VS, but never seem to be high enough priority to implement in the CLR. Perhaps go upvote it here:

http://connect.microsoft.com/VisualStudio/feedback/details/333647/data-breakpoints-in-managed-code

0

精彩评论

暂无评论...
验证码 换一张
取 消