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

[via lldb-dev]

> -----Original Message-----
> From: Matthias Braun [mailto:matze at braunis.de]
> Sent: Wednesday, October 10, 2018 3:48 PM
> To: Robinson, Paul
> Cc: jingham at apple.com; vsk at apple.com; llvm-commits at lists.llvm.org; lldb-
> dev at lists.llvm.org
> Subject: Re: [lldb-dev] [llvm] r343874 - DwarfDebug: Pick next location in
> case of missing location at block begin
> 
> 
> 
> > 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.

Temper, temper.

The line tables are there for a reason. Actually multiple reasons. I have
been fussing with them for years and it is not easy to get them to work
for all consumers. Work with me here, please.
--paulr

> But before I have to go
> hunting down lldb bugs as the next step in the yak shaving I will
> revert...