[llvm-dev] [RFC] Displaying source variable locations in llvm-objdump

[Eric Christopher via llvm-dev]

My general perspective here is that it'll be useful to put into a library
at some point. I'd like to see a collection of a lot of the functionality
from readelf and objdump to make its way out of the tool and into the
library in general.

-eric

On Mon, Dec 9, 2019 at 4:58 PM Jameson Nash via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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.
>
> 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
> https://gist.github.com/vtjnash/2f2b642663655d5fc63ec7321c5bd0bd,
> implementation
> https://github.com/JuliaLang/julia/blob/master/src/disasm.cpp#L167), 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.
>
> 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.
>
> -jameson
>
> On Wed, Nov 27, 2019 at 1:51 PM Sean Silva via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> This looks fantastic. It will be a big time saver for folks staring at
>> assembly.
>>
>> — Sean Silva
>>
>> On Tue, Nov 26, 2019 at 8:50 AM Oliver Stannard via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hi llvm-dev,
>>>
>>> I've uploaded a prototype patch at https://reviews.llvm.org/D70720
>>> 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 https://reviews.llvm.org/M2.
>>>
>>> I have two use-cases in mind for this:
>>> * 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.
>>> * 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.
>>>
>>> My questions for the LLVM community are:
>>> * Is this an acceptable change for llvm-objdump, or is this adding too
>>> much complexity to be worth it?
>>> * 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?
>>> * 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.
>>>
>>> Oliver
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191209/45ed4b6a/attachment.html>