If you set a breakpoint on source lines with no line table entries, lldb slides
the actual match forward to the nearest line table entry to the given line
number. That's necessary for instance because if you lay out your function
definitions over multiple lines they won't all get line table entries, but we
don't want people to have to guess which of them was... Same is true of more
complicated compound statements.
So people like that, but they really hate it when they have:
#ifdef SOMETHING_NOT_DEFINED
int foo() {
}
#else
int bar() {
}
#end
but with lots more junk so you can't see the ifdef's and then they set a
breakpoint in the "int foo" part and the breakpoint gets moved to bar instead
and then doesn't get hit. You might try to argue that they should have checked
where the breakpoint actually landed before coming into your office to yell at
you, but it's likely to leave you with fewer friends...
So I was trying to detect this case and not move the breakpoint if sliding it
crossed over the function start boundary. That way you'd see that the
breakpoint didn't work, and go figure out why.
The thinko in the original version was that we were still doing this when we
DIDN'T have to slide the breakpoint, when we got an exact match in the line
table. In that case, we shouldn't try to second guess the line table at all.
That's the patch in this fix.
BTW, the check wouldn't have affected code from .defs files because I only do
it if the original breakpoint specification and the "function start" are from
the same source file. And we know about inlined blocks so inlining isn't going
to fool us either.
Jim
> On Jan 15, 2021, at 5:09 PM, David Blaikie <dblai...@gmail.com> wrote:
>
> "But because their source lines are outside the function source range"
>
> Not sure I understand that - the DWARF doesn't describe a function
> source range, right? Only the line a function starts on. And a
> function can have code from source lines in many files/offsets that
> are unrelated to the function start line (LLVM in several places
> #includes .def files into functions to stamp out tables, switches,
> arrays, etc, for instance)
>
> On Fri, Jan 15, 2021 at 4:47 PM Jim Ingham via Phabricator via
> lldb-commits <lldb-commits@lists.llvm.org> wrote:
>>
>> jingham created this revision.
>> jingham requested review of this revision.
>> Herald added a project: LLDB.
>> Herald added a subscriber: lldb-commits.
>>
>> The inline initializers contribute code to the constructor(s). You will
>> step onto them in the source view as you step through the constructor, for
>> instance. But because their source lines are outside the function source
>> range, lldb thought a breakpoint on the initializer line was crossing from
>> one function to another, which file & line breakpoints don't allow. That
>> meant if you tried to set a breakpoint on one of these lines it doesn't
>> create any locations.
>>
>> This patch fixes that by asserting that if the LineEntry in one of the
>> SymbolContexts that the search produced exactly matches the file & line
>> specifications in the breakpoint, it has to be a valid place to set the
>> breakpoint, and we should just set it.
>>
>>
>> Repository:
>> rG LLVM Github Monorepo
>>
>> https://reviews.llvm.org/D94846
>>
>> Files:
>> lldb/source/Breakpoint/BreakpointResolverFileLine.cpp
>> lldb/test/API/lang/cpp/break-on-initializers/Makefile
>> lldb/test/API/lang/cpp/break-on-initializers/TestBreakOnCPP11Initializers.py
>> lldb/test/API/lang/cpp/break-on-initializers/main.cpp
>>
>> _______________________________________________
>> lldb-commits mailing list
>> lldb-commits@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
