> On Oct 7, 2015, at 5:07 PM, Jim Ingham <jing...@apple.com> wrote: > > Another way to do this - which I thought about originally but rejected as too > much delicate machinery for the desired effect - is to add the notion of > "clusters" of locations to the breakpoint. Instead of eliding all the > segments with the same line number into one location, you'd make a location > per segment but treat them as a cluster, where a hit on one location in the > cluster would set a flag telling you to auto-continue the other locations in > the cluster till "something happened to reset the cluster". You'd have to > figure out good heuristics for that "something happened". You could probably > get away with "frame changed" and "hit the location that I hit the first time > I hit the cluster". But I'd have to think a bit harder about this to assure > myself this was good enough. And you'd have to keep a side table of history > for each breakpoint which you'd have to manage... Nothing impossible, but it > didn't seem worth the effort at the time. > > Anyway, if you are sufficiently motivated to give this a try, it would be a > more general solution to the problem without requiring user intervention - > either having to press continue some undetermined number of times, or create > the breakpoints with some special option.
BTW, Greg points out that one could teach the Thread Plans to treat step over a source line that has a breakpoint on it to do this job as well. That will save you from having to store history information off to one side. This approach might be worth pursuing, though I bet it will end up being trickier than it seems at first glance... Jim > >> >>> The motivation is that compilers in general and certainly clang in >>> particular love to put multiple line table entries in for a given line that >>> are either contiguous or interrupted by artificial book-keeping code. So >>> if we didn???t coalesce these line entries, when you set a breakpoint on >>> such a line, you??????d have to hit continue some unpredictable number of >>> times before you actually get past that line. You could figure out how >>> many time by counting the number of locations, but nobody could be expected >>> to do that??? And if you are chasing multiple hits of the breakpoint >>> through code it was really a pain since one ???continue??? didn???t result >>> in one pass through the function containing the code. This happens very >>> frequently and was a font of bugs for lldb early on. >> >> Understood - we get reports like this all the time, and I've also thought of >> ways to workaround it, but for each idea I had, I could always find a way to >> break it. So now I tell users it "works as designed", and that it's better >> to hit a BP a couple times than none at all. >> >>> Note, this doesn???t affect the stepping algorithms, since when we step we >>> just look at where we land and if it has the same line number as we were >>> stepping through we keep going. Of course, it also makes stepping over >>> such a line annoying for the same reason that it made continue annoying... >> >> What about tail recursion? You must at least check the stack ptr, no? > _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
