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

[Michael Spencer via llvm-dev]

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
>

This is a great addition to llvm-objdump. My only concern is that
llvm-objdump.cpp is already pretty complicated and in need of refactoring
as it's had lots of small features added over the years. I'd really like to
see the disassembly formatting stuff moved out to another file, but I'm not
sure that should be a blocker.

While I really like the unicode, it won't work on Windows by default. It
would be nice if we could detect if the terminal supported unicode, but I'm
not sure there's actually a good way to do that.

- Michael Spencer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191211/ce52a192/attachment.html>