[lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in case of missing location at block begin

[Matthias Braun via llvm-commits]

> On Oct 10, 2018, at 12:18 PM, via llvm-commits <llvm-commits at lists.llvm.org> wrote:
> 
> 
> 
>> -----Original Message-----
>> From: jingham at apple.com [mailto:jingham at apple.com]
>> Sent: Wednesday, October 10, 2018 2:20 PM
>> To: Vedant Kumar
>> Cc: Robinson, Paul; Vedant Kumar via llvm-commits; LLDB; Matthias Braun
>> Subject: Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in
>> case of missing location at block begin
>> 
>> 
>> 
>>> On Oct 10, 2018, at 9:54 AM, Vedant Kumar <vsk at apple.com> wrote:
>>> 
>>>> On Oct 10, 2018, at 9:16 AM, Matthias Braun <matze at braunis.de> wrote:
>>>> 
>>>> So I haven't worked much on debug info, but here's the explanation for
>> my patches:
>>>> My original motivation was getting rid of code some code in the llvm
>> codegen that for spills and reloads just picked the next debug location
>> around. That just seemed wrong to me, as spills and reloads really are
>> bookkeeping, we just move values around between registers and memory and
>> none of it is related to anything the user wrote in the source program. So
>> not assigning any debug information felt right for these instructions.
>> Then people noticed line table bloat because of this and I guess we
>> assumed that having exact line-0 annotations isn't that useful that it
>> warrants bloating the debug information...
>>> 
>>> Right. This doesn't seem any more arbitrary than reusing the previous
>> instruction location, which we do all the time. I think it's a reasonable
>> tradeoff.
> 
> For spills and reloads, the next valid source location might be reasonable.
> For top-of-block instructions, I really don't think so; we had this issue
> in FastISel, some years back, and ultimately went with line-0 at top of 
> block because it caused way fewer problems than hoisting the next valid 
> source location.
> 
> Please revert, and make top-of-block not work the same as spills and reloads.
I still do not understand why the new behavior would be a problem. What does the debugger do with line-0 location except for setting the breakpoints slightly later? Spills/reloads being attribute to a following line or not, how would that make a difference?

I don't really care about the commit itself, it was the third step in a yak-shaving situation. If you prefer bigger line tables then why not (though then you should just enable the "UnknownLocations=Enable" behavior in DwarfDebug.cpp to at least be consistent. But before I have to go hunting down lldb bugs as the next step in the yak shaving I will revert...