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

[via lldb-dev]

On Mon, Oct 05, 2015 at 03:01:28PM -0700, Jim Ingham wrote:
> 
> Given that, the best lldb can do is use heuristics, and the best heuristic I had was Block == basic block???  

Can you at least check for branches then?  (Yes, that would require dissassebly).

> 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?  

> Note also that gdb plays the same trick with setting breakpoints on multiple line table entries (or at least it did last time I looked.)  This wasn???t something new in lldb.

No, gdb gets this case right.

> Yours is the first report we???ve had where this causes trouble, whereas it makes general stepping work much more nicely.

I'm quite surprised.  FWIW, the typical case we see this in is exception handling.

> So if you have some specific reason to need it either (a) if there???s some better heuristic you can come up with that detects when you should not coalesce, that would be awesome 

Better: check for branches out of the block.

But this would still fail for cases where code branches around the initial block
and into the blocks belonging to that line further down.

    ; Example pseudo code: Set BP at line 10 in the following:
          br @lbl2                  ; belongs to line 9
    lbl1: insns_for_line10_part1    ; lldb sets BP here
    lbl2: insns_for_line10_part2    ; BP at line 10 never hit
          if (false_cond) br @lbl1

So best would be to also check for labels which lines into the block, 
but that's unrealistic.
    
> or (b) if there???s no way lldb can tell, you???ll have to add an option.

Sounds like we'll have to go with an option then.

Thanks,
-Dawn