> -----Original Message----- > From: Matthias Braun [mailto:ma...@braunis.de] > Sent: Wednesday, October 10, 2018 3:48 PM > To: Robinson, Paul > Cc: jing...@apple.com; v...@apple.com; llvm-comm...@lists.llvm.org; lldb- > d...@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- > comm...@lists.llvm.org> wrote: > > > > > > > >> -----Original Message----- > >> From: jing...@apple.com [mailto:jing...@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 <v...@apple.com> wrote: > >>> > >>>> On Oct 10, 2018, at 9:16 AM, Matthias Braun <ma...@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... _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
