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

[Jeremy Morse via llvm-dev]

Hi Oliver,

On Tue, Nov 26, 2019 at 4:50 PM Oliver Stannard via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 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 haven't read the code yet, but the demo looks incredibly good, and
I'd certainly find this feature useful on a daily basis. Many thanks
for writing it!

Oliver wrote:
> * 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?

I enjoy a plain ASCII aesthetic myself, but I feel the extra detail is
really contributing a lot, for example distinguishing the location
range from the variable name connection (the former thick, the latter
thin). IMHO, well worth keeping the unicode.

> * 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.

I'm not aware of existing syntax, when printing assembly LLVM will add
comments where variable ranges start such as [0]. AFAIUI that only
ever prints the base register, an initial memory deref (like [SP+4] as
your demo shows), and the rest of the expression is printed as
text/opcodes as here [1].

I reckon that outside of the two common cases you describe, it would
be enough to flag that there's extra unshown expression to consider,
by appending a star for example. The rest of the expression is easily
accessible to a developer, and displaying expressions isn't the
primary aim of the patch.

I'll get round to looking at the patch in a bit.

[0] https://github.com/llvm/llvm-project/blob/1433b1b6ec7e1c2b2a91d2070dcd88adf1aa9774/llvm/test/tools/llvm-symbolizer/frame-types.s#L99
[1] https://github.com/llvm/llvm-project/blob/abf25745b339700639a5d319551ed120a52fd753/llvm/test/tools/llvm-dwarfdump/X86/Inputs/statistics-fib.split-dwarf.s#L115

--
Thanks,
Jeremy