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

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

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>

+1 to this comment. It has always felt weird to me that we have a
non-trivial amount of duplicate functionality with independent
implementations in the two tools, when we could pull much of it into
libObject or similar. Printing of the data would need to continue to be
independent of llvm-readelf/llvm-objdump etc since they do that
differently, but the parsing should be identical.

James

On Tue, 10 Dec 2019 at 01:07, Eric Christopher via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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
>>
> _______________________________________________
> 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/20191210/2bc70ea3/attachment.html>