1) So I went and figured out why the lldb testcase at hand fails. - It seems the debugger stepping logic will follow the program along until it finds a new source location. However if that new source location is part of a new DW_AT_abstract_location it is ignored in the step over mode. - In the testcase at hand the .loc location of an inlined function was moved to an earlier place without the DW_AT_abstract_location entry getting extended. So the debugger mistook the inlined function as the same scope and stepping incorrectly halted there.
On the LLVM side DW_AT_abstract_location is generated by LexicalScopes which is created by lib/CodeGen/LexicalScopes.cpp / extractLexicalScopes() with completely separate code from the line table generation code in lib/CodeGen/AsmPrinter/DwarfDebug.cpp you have to be aware of that and keep the two algorithms in sync :-/ I fixed LexicalScopes.cpp to be in sync and the lldb test works fine again for me. 2) However talking to Adrian earlier he also expressed having a bad feeling about moving debug location upwards instead of emitting line-0 entries. So I think consensus here is to rather live with some line table bloat instead. - Unless there are objections I will not go with option 1) but instead revert this commit tomorrow. Note that I will only revert r343874 (i.e. the behavior change for what to emit when the first instructions of a basic block have no location attached), but not r343895 (removing debuglocs from spill/reload instructions) as I still consider this a sensible commit. So in the end we may have bigger line tables than before my changes, but simpler code in the spill/reload generation and occasionally can avoid random source location when spill/reloads get rescheduled. - Matthias > On Oct 10, 2018, at 1:17 PM, via llvm-commits <llvm-comm...@lists.llvm.org> > wrote: > > > >> -----Original Message----- >> From: Matthias Braun [mailto:ma...@braunis.de] >> Sent: Wednesday, October 10, 2018 3:50 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. >> >> I assume what happened in the past was that the previous debug location >> spilled over to the next basic block when the top-of-the-block instruction >> had line-0 set. I can immediately see why that is a problem. And I assume >> that was the case that was overlooked in the past. I cannot see however >> how taking the following location in the same basic block is a problem. > > Because those instructions actually do something, and whether variables are > visible and expressions evaluate correctly may depend on those instructions > being executed before the debugger stops. If you mark them with line 0 the > debugger doesn't stop. If you hoist the next source location, it does. > > Spills and reloads in the middle of a block *probably* can be associated > with the next source line without doing any real damage; although it may > turn out that reloads need to attach to the previous source line. I'd > need to see a variety of examples to be sure, one way or the other. > > But long experience has taught me that instructions at the top of a block > really are better off at line 0 than at the next real source line. If > you can prove they are *always* better off with the next source line, for > all consumers, I'd be very interested to hear about it. > > But, this thread is not the best place for that; bring it up on llvm-dev > so other interested parties can see what you're looking for. > --paulr > > _______________________________________________ > llvm-commits mailing list > llvm-comm...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
