[Lldb-commits] [PATCH] D91734: [FastISel] Flush local value map on every instruction

[Jim Ingham via llvm-commits]

> On Dec 3, 2020, at 5:43 PM, Robinson, Paul <paul.robinson at sony.com> wrote:
> 
> 
> 
>> -----Original Message-----
>> From: Jim Ingham <jingham at apple.com <mailto:jingham at apple.com>>
>> Sent: Thursday, December 3, 2020 5:51 PM
>> To: David Blaikie
>> <reviews+D91734+public+9741d1f0c1792e0e at reviews.llvm.org <mailto:reviews+D91734+public+9741d1f0c1792e0e at reviews.llvm.org>>; David Blaikie
>> via Phabricator <reviews at reviews.llvm.org <mailto:reviews at reviews.llvm.org>>
>> Cc: Robinson, Paul <paul.robinson at sony.com <mailto:paul.robinson at sony.com>>; rnk at google.com <mailto:rnk at google.com>;
>> echristo at gmail.com <mailto:echristo at gmail.com>; sontuan.vu119 at gmail.com <mailto:sontuan.vu119 at gmail.com>; mcrosier at codeaurora.org <mailto:mcrosier at codeaurora.org>;
>> nikola.tesic at syrmia.com <mailto:nikola.tesic at syrmia.com>; lldb-commits <lldb-commits at lists.llvm.org <mailto:lldb-commits at lists.llvm.org>>;
>> Liburd1994 at outlook.com <mailto:Liburd1994 at outlook.com>; stefan.graenitz at gmail.com <mailto:stefan.graenitz at gmail.com>; matze at braunis.de <mailto:matze at braunis.de>;
>> nemanja.i.ibm at gmail.com <mailto:nemanja.i.ibm at gmail.com>; simon.dardis at gmail.com <mailto:simon.dardis at gmail.com>; Tozer, Stephen
>> <stephen.tozer at sony.com <mailto:stephen.tozer at sony.com>>; AlokKumar.Sharma at amd.com <mailto:AlokKumar.Sharma at amd.com>; sbc at chromium.org <mailto:sbc at chromium.org>;
>> sourabhsingh.tomar at amd.com <mailto:sourabhsingh.tomar at amd.com>; Jackson, Chris <chris.jackson at sony.com <mailto:chris.jackson at sony.com>>;
>> arphaman at gmail.com <mailto:arphaman at gmail.com>; jji at us.ibm.com <mailto:jji at us.ibm.com>; 88888yl at gmail.com <mailto:88888yl at gmail.com>;
>> horse10241024 at gmail.com <mailto:horse10241024 at gmail.com>; pengfei.wang at intel.com <mailto:pengfei.wang at intel.com>; david.green at arm.com <mailto:david.green at arm.com>;
>> higuoxing at gmail.com <mailto:higuoxing at gmail.com>; ikudrin at accesssoftek.com <mailto:ikudrin at accesssoftek.com>; p8u8i7l5t1q9r8w3 at ibm-
>> systems-z.slack.com <http://systems-z.slack.com/>; Enciso, Carlos <Carlos.Enciso at sony.com <mailto:Carlos.Enciso at sony.com>>; llvm-
>> commits at lists.llvm.org <mailto:commits at lists.llvm.org>; Cazalet-Hyams, Orlando <orlando.hyams at sony.com <mailto:orlando.hyams at sony.com>>;
>> asowda at cisco.com <mailto:asowda at cisco.com>; sanimir at subpath.org <mailto:sanimir at subpath.org>; simon at atanasyan.com <mailto:simon at atanasyan.com>;
>> jrtc27 at jrtc27.com <mailto:jrtc27 at jrtc27.com>; djordje.todorovic at syrmia.com <mailto:djordje.todorovic at syrmia.com>; ch.bessonova at gmail.com <mailto:ch.bessonova at gmail.com>;
>> quentin.colombet at gmail.com <mailto:quentin.colombet at gmail.com>; akhuang at google.com <mailto:akhuang at google.com>; aheejin at gmail.com <mailto:aheejin at gmail.com>;
>> avl.lapshin at gmail.com <mailto:avl.lapshin at gmail.com>; david.stenberg at ericsson.com <mailto:david.stenberg at ericsson.com>;
>> david.spickett at linaro.org <mailto:david.spickett at linaro.org>; dougpuob at gmail.com <mailto:dougpuob at gmail.com>; bhuvanendra.kumarn at amd.com <mailto:bhuvanendra.kumarn at amd.com>;
>> serhiy.redko at gmail.com <mailto:serhiy.redko at gmail.com>; jini.susan.george at gmail.com <mailto:jini.susan.george at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20201203/6c0ff711/attachment.html>