[lldb-dev] lldb fails to hit breakpoint when line maps to multiple addresses

[Jim Ingham via lldb-dev]

> On Oct 7, 2015, at 5:07 PM, Jim Ingham <jingham at 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?
>