[PATCH] D83468: [Debuginfo] Fix for PR46653

Wed Aug 19 10:00:38 PDT 2020

jingham added a comment.

In D83468#2226461 <https://reviews.llvm.org/D83468#2226461>, @aprantl wrote:

> In D83468#2224774 <https://reviews.llvm.org/D83468#2224774>, @dblaikie wrote:
>
>> In D83468#2224754 <https://reviews.llvm.org/D83468#2224754>, @aprantl wrote:
>>
>>>> (gdb) b main
>>>> Breakpoint 1 at 0x800005ec: file test.c, line 0.
>>>
>>> Agreed that that is not a helpful end-user experience.
>>
>> How does LLDB handle this? Might also be consumer-fixable.
>
> My understanding is that like with a regular breakpoint it would also slide the prologue-end breakpoint forward to the first non-zero line number. I'm not sure what happens if it's line 0 all the way to the end of the basic block — I think it would break on line 0 in that case. @jingham can correct me.

This is done in Function::GetPrologueByteSize.  The computation there is pretty aggressive, and so long as the first non-zero line is before the end of the function we'll slide it to there.  So the only case where we would set the breakpoint on line 0 is if the whole function has line-number 0.

I have one bug where the branching part of a switch statement that is the first line of a function got absorbed by line number 0 (most likely a debug info bug) so that the breakpoint got slid to the first case of the switch.  At some point I need to refine the prologue skipping code so that it doesn't skip past branches.  This isn't 100% trivial since there are branches that naturally occur in prologues like the "branch to next instruction" trick which some systems use in the prologue to read out the pc.  And some architectures have "set up all the FP register functions" that get called in prologues as well.

Anyway, that stream of consciousness comment is off-topic.  To answer Adrian's question, we push the prologue to the first non-zero line as long as there is one in the function.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83468/new/

https://reviews.llvm.org/D83468