<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">I agree with the others that this seems great! I think this information can be super helpful for users both in learning and skimming assembly codes.<div><br></div><div>As a maintainer of a LLVM frontend (JuliaLang), I'm additionally interested in whether some bits of this make sense to end up in libLLVM itself. Probably especially the collection code pieces. For context, I've previously written some code to pretty-print the line-table information as code comments (sample <a href="https://gist.github.com/vtjnash/2f2b642663655d5fc63ec7321c5bd0bd" target="_blank">https://gist.github.com/vtjnash/2f2b642663655d5fc63ec7321c5bd0bd</a>, implementation <a href="https://github.com/JuliaLang/julia/blob/master/src/disasm.cpp#L167" target="_blank">https://github.com/JuliaLang/julia/blob/master/src/disasm.cpp#L167</a>), and it's been on my mind ever since to figure out if some portion of that made sense to upstream, if any. And also to figure out how to parse and show the variable info along it. So even if none of this PR ends up in the libllvm library, I'd still plan to someday figure out which bits of this PR to copy into our AssemblyAnnotationWriter to show the variable info in our front-end also. </div><div><br></div><div>But if it does get put in libLLVM, this capability seems like it could be useful for the other instruction printers too (e.g. IR and MIR). So I'd be interested to hear if you have any thoughts on what might make sense in a library, and any other opportunities where I could help collaborate. This shouldn't need to delay review and merging of your current PR though.</div><div><br></div><div>-jameson</div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 27, 2019 at 1:51 PM Sean Silva via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div dir="auto">This looks fantastic. It will be a big time saver for folks staring at assembly.</div></div><div dir="auto"><br></div><div dir="auto">— Sean Silva</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 26, 2019 at 8:50 AM Oliver Stannard via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi llvm-dev,<br><br>I've uploaded a prototype patch at <a href="https://reviews.llvm.org/D70720" target="_blank">https://reviews.llvm.org/D70720</a> which adds a new feature to llvm-objdump: displaying the location (in registers/memory/etc) of source-level variables alongside the disassembly display. I've put a demo of the output at <a href="https://reviews.llvm.org/M2" target="_blank">https://reviews.llvm.org/M2</a>.<br><br>I have two use-cases in mind for this:<br>* Users reading the disassembly of compiled code. It will be quicker/easier to do this if the disassembly shows which value is in each register and stack slot, rather than the user having to reverse-engineer this by hand.<br>* Compiler developers, who can use it to understand the debug info emitted by the compiler, and spot missing or incorrect debug info. In fact, I've already spotted one LLVM bug while writing this patch: in the function `baz` in M2, the debug info claims that variable `a` is in `r0` between PC addresses 0x14 and 0x8, which isn't true.<br><br>My questions for the LLVM community are:<br>* Is this an acceptable change for llvm-objdump, or is this adding too much complexity to be worth it?<br>* The patch currently uses unicode box-drawing characters, is this OK? If not, what would people rather see? A plain ASCII version of this, or some completely different format?<br>* The patch displays DWARF expressions in an ad-hoc syntax, which is a mix of C and ARM assembly (square brackets for memory access). Is there an existing syntax which would be better for this? I think it's important that the common cases like "load 4 bytes from memory at SP+4" are displayed concisely.<br><br>Oliver<br></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>