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

[Sean Silva via llvm-dev]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191127/295ff925/attachment.html>