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

[James Henderson via llvm-dev]

I quite like the look of this in principle too, and I see no reason it
couldn't be added as an option in llvm-objdump. Have you experimented with
this on a Windows command prompt (PowerShell and cmd)? My experience with
unicode characters in those has shown that unicode characters don't always
work particularly well.

I don't think that should be a blocker on this feature mind you, but if it
is problematic, we might just want to fall back to standard ASCII
characters ('|', '+', '-' etc).

I'll take a look at the patch in due course.

James

On Tue, 26 Nov 2019 at 18:39, Evgenii Stepanov via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi,
>
> I like this a lot! I think the dwarf expression syntax is spot-on.
>
> On Tue, Nov 26, 2019 at 9:12 AM Eric Christopher <echristo at gmail.com>
> wrote:
>
>> Hi Oliver,
>>
>> This is really cool. I absolutely support this for llvm-objdump. As
>> far as output I don't have any strong opinions other than it might be
>> good to separate out the "drawing" code as much as possible from the
>> variable collection and range code to make it a little easier, but
>> that's about it from here.
>>
>> Thanks for the work, can't wait to use it.
>>
>> -eric
>>
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191127/8adedd95/attachment.html>