> On Dec 3, 2020, at 5:43 PM, Robinson, Paul <paul.robin...@sony.com> wrote: > > > >> -----Original Message----- >> From: Jim Ingham <jing...@apple.com <mailto:jing...@apple.com>> >> Sent: Thursday, December 3, 2020 5:51 PM >> To: David Blaikie >> <reviews+d91734+public+9741d1f0c1792...@reviews.llvm.org >> <mailto:reviews+d91734+public+9741d1f0c1792...@reviews.llvm.org>>; David >> Blaikie >> via Phabricator <revi...@reviews.llvm.org <mailto:revi...@reviews.llvm.org>> >> Cc: Robinson, Paul <paul.robin...@sony.com <mailto:paul.robin...@sony.com>>; >> r...@google.com <mailto:r...@google.com>; >> echri...@gmail.com <mailto:echri...@gmail.com>; sontuan.vu...@gmail.com >> <mailto:sontuan.vu...@gmail.com>; mcros...@codeaurora.org >> <mailto:mcros...@codeaurora.org>; >> nikola.te...@syrmia.com <mailto:nikola.te...@syrmia.com>; lldb-commits >> <lldb-commits@lists.llvm.org <mailto:lldb-commits@lists.llvm.org>>; >> liburd1...@outlook.com <mailto:liburd1...@outlook.com>; >> stefan.graen...@gmail.com <mailto:stefan.graen...@gmail.com>; >> ma...@braunis.de <mailto:ma...@braunis.de>; >> nemanja.i....@gmail.com <mailto:nemanja.i....@gmail.com>; >> simon.dar...@gmail.com <mailto:simon.dar...@gmail.com>; Tozer, Stephen >> <stephen.to...@sony.com <mailto:stephen.to...@sony.com>>; >> alokkumar.sha...@amd.com <mailto:alokkumar.sha...@amd.com>; >> s...@chromium.org <mailto:s...@chromium.org>; >> sourabhsingh.to...@amd.com <mailto:sourabhsingh.to...@amd.com>; Jackson, >> Chris <chris.jack...@sony.com <mailto:chris.jack...@sony.com>>; >> arpha...@gmail.com <mailto:arpha...@gmail.com>; j...@us.ibm.com >> <mailto:j...@us.ibm.com>; 8888...@gmail.com <mailto:8888...@gmail.com>; >> horse10241...@gmail.com <mailto:horse10241...@gmail.com>; >> pengfei.w...@intel.com <mailto:pengfei.w...@intel.com>; david.gr...@arm.com >> <mailto:david.gr...@arm.com>; >> higuox...@gmail.com <mailto:higuox...@gmail.com>; ikud...@accesssoftek.com >> <mailto:ikud...@accesssoftek.com>; p8u8i7l5t1q9r8w3@ibm- >> systems-z.slack.com <http://systems-z.slack.com/>; Enciso, Carlos >> <carlos.enc...@sony.com <mailto:carlos.enc...@sony.com>>; llvm- >> comm...@lists.llvm.org <mailto:comm...@lists.llvm.org>; Cazalet-Hyams, >> Orlando <orlando.hy...@sony.com <mailto:orlando.hy...@sony.com>>; >> aso...@cisco.com <mailto:aso...@cisco.com>; sani...@subpath.org >> <mailto:sani...@subpath.org>; si...@atanasyan.com >> <mailto:si...@atanasyan.com>; >> jrt...@jrtc27.com <mailto:jrt...@jrtc27.com>; djordje.todoro...@syrmia.com >> <mailto:djordje.todoro...@syrmia.com>; ch.besson...@gmail.com >> <mailto:ch.besson...@gmail.com>; >> quentin.colom...@gmail.com <mailto:quentin.colom...@gmail.com>; >> akhu...@google.com <mailto:akhu...@google.com>; ahee...@gmail.com >> <mailto:ahee...@gmail.com>; >> avl.laps...@gmail.com <mailto:avl.laps...@gmail.com>; >> david.stenb...@ericsson.com <mailto:david.stenb...@ericsson.com>; >> david.spick...@linaro.org <mailto:david.spick...@linaro.org>; >> dougp...@gmail.com <mailto:dougp...@gmail.com>; bhuvanendra.kum...@amd.com >> <mailto:bhuvanendra.kum...@amd.com>; >> serhiy.re...@gmail.com <mailto:serhiy.re...@gmail.com>; >> jini.susan.geo...@gmail.com <mailto:jini.susan.geo...@gmail.com> >> Subject: Re: [Lldb-commits] [PATCH] D91734: [FastISel] Flush local value >> map on every instruction >> >> Note, lldb has a bunch of special handling for line 0 code. For instance, >> when we are pushing a breakpoint past the prologue we will keep pushing it >> forward over line number 0 lines. Those are compiler generated and in >> general people don't want to stop there. Similarly, if you are stepping >> through line 3 and the next line entry after 3 is line 0 we keep stepping >> till we get to a non-zero line. >> >> When the compiler is actually using line 0 to mean "compiler generated >> code not really associated with a particular line, then I am pretty sure >> the debugger has to be aware of this or debugging is going to be a bit >> awkward... >> >> I don't know if that's directly relevant to this bug, I haven't had time >> to follow the whole discussion. But I'm not convinced all the problems >> with line 0 emission causing debugging oddities can be solved in the line >> table generation. >> >> Jim > > Hi Jim, > > This issue is not really "line 0 causing debugger oddities" so much as > "line 0 attached to instructions that should have a real line number." > > It's true that gdb's response to line 0 on the first instruction past > the prologue_end seems a tad idiosyncratic, but if nothing else, it > exposed an issue in the compiler that is worth solving. There are > clearly instructions attributed to line 0 that shouldn't be, and the > goal here is to make that better.
That's great! Getting all the instructions you can assigned correctly to real lines is worthy labor! Once you are all done with that work, given you really are using line 0 for real instances of compiler generated code that aren't attributable to any one line, stepping in gdb is going to look odd sometimes if gdb doesn't know to handle them. It might be worth filing some bugs with gdb to cope with this situation (though its probably better to use examples where the line 0 is correctly attributed...) Jim > > Thanks, > --paulr
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
