[lldb-dev] lldb fails to hit breakpoint when line maps to multiple addresses
Jim Ingham via lldb-dev
lldb-dev at lists.llvm.org
Mon Oct 5 15:01:28 PDT 2015
> On Sep 23, 2015, at 6:39 PM, dawn at burble.org wrote:
> On Wed, Sep 23, 2015 at 11:44:41AM -0700, Greg Clayton wrote:
>> We currently coalesce breakpoints to avoid the user stopping multiple times on the same source line. This might have been done to avoid stepping issues we might have had in the past, but we have made many modifications to stepping such that the step thread plans now know how to step through two hits from the same source line. I would need Jim to confirm this, but he is out for 2 weeks.
> I (think I) understand the intent, but it is wrong as written. What I
> think the code is trying to do is remove duplicate lines within a basic
> block (or at least that's the only explanation I can come up with that
> makes any sense), but the code appears to assume Block == basic block,
> which is not true.
The debugger doesn’t really know anything about basic blocks. IIRC there is a way to specify this in the DWARF line tables but nobody sets it so we don’t try to use it.
Given that, the best lldb can do is use heuristics, and the best heuristic I had was Block == basic block…
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.
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...
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.
I don’t think it will make people happy to turn this coalescing off by default, I would urge you not to do that. Yours is the first report we’ve had where this causes trouble, whereas it makes general stepping work much more nicely. 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 or (b) if there’s no way lldb can tell, you’ll have to add an option.
> As long as there is branching into/out of an address range, you can miss
> breakpoints, which is much worse than stepping to the same line twice,
> wouldn't you agree? Note that this isn't even in optimized code - this
> issue will be far more common after the optimizer has played with it.
> As you say, we might have to wait for Jim to hear the real answer.
> If this turns out to be intentional, OK to add an option to control it?
>> So this is on purpose and is expected. Not sure what will happen if we disable this coalescing of locations that are contiguous. Feel free to try and disable it and run the test suite and see how things go. Don't check anything in, but you could try disabling it on your branch and see how things go. Then when Jim returns we can confirm with him what the right thing to do is.
> Sure - will do.
More information about the lldb-dev