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

Robinson, Paul via llvm-commits llvm-commits at lists.llvm.org
Thu Dec 3 17:43:23 PST 2020



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

Thanks,
--paulr


More information about the llvm-commits mailing list