<div dir="ltr"><div><div><div><div>I worked with LLVM for years and never knew there was an IR debugger.  At that stage of my time with it lowering issues / crashes were a bigger problem than code, and assembly language can be correlated to IR in my head pretty accurately because I'm strange that way, so I never looked.  I don't use it as much anymore but I'm sure some people would be interested. <br><br></div><div>If the IR won't lower, this pass won't work, correct?   As I said I'm unfamiliar. <br></div><div><br></div>To play devil's advocate, what happens if you need to debug IR from 2 years ago or an unknown build?  As long as the IR is compatible the two years situation works, but if it doesn't and for whatever catastrophe that's all you have, what do you do about it?  IR could be the cause of a bug in one revision and a subtle fix makes it pointless to debug two revisions later without breaking anything and vice versa.   <br>It doesn't happen as much anymore, but it happens.  That was kind of a rhetorical question since I already know what happens when you mix somewhat compatible IR versions. <br><br></div>Since I'm not familiar with the original pass, does this step through *and* attempt lowering?   I know we need an MBB to lower, but being able to ID the exact line of IR causing the lowering error could help nicely.  At O0 there isn't much going on in terms of block changes so it seems reasonable to match up an error to the producing line from what I know of the debug system.  There would be problems (Dummy MBBs for targets / unseen preds off the top of my head), but it would be a step up from doing pass debugging directly.  <br><br></div>Since you're more familiar with this, how hard do you think implementing something like that would be, on a scale of 1 to go away with that nonsense.  :-)<br><br><br></div>_GK_<br><div><div><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 4, 2018 at 2:09 AM, Tim Northover via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 4 January 2018 at 07:11, Brenda So via llvm-dev<br>
<span class=""><<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> interesting ... just curious, why did they delete "-debug-ir" to begin with ?<br>
<br>
</span>The metadata describing the information debuggers need (line numbers,<br>
variable locations and so on) was evolving rapidly at the time I<br>
think. The -debug-ir pass was lagging behind I think, and rarely used<br>
as far as anyone knew.<br>
<span class=""><br>
> Also, it's extremely interesting that gdb and lldb can be used to debug LLVM IR. How does your code work (on a high level)? A high level explanation will help me understand what you've done better.<br>
<br>
</span>It adds the information necessary to produce normal DWARF debugging<br>
information in the object files. That format is designed to be<br>
generic.<br>
<br>
One part is just mapping some byte of the output instructions back to<br>
the source file and line number, which is just as easy for IR as for a<br>
more conventional language. The other major part is describing where<br>
in memory or registers named variables are, which is also pretty much<br>
the same for LLVM IR as for normal code. After that the magic of<br>
debuggers takes over.<br>
<br>
Cheers.<br>
<br>
Tim.<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div></div></div>