[LLVMdev] llvm-dwarfdump improvements

David Blaikie dblaikie at gmail.com
Wed Sep 3 09:41:52 PDT 2014


On Wed, Sep 3, 2014 at 9:30 AM, Frédéric Riss <friss at apple.com> wrote:

> Hi,
>
> [ I think I put the most important contributors to the DebugInfo stuff in
> Cc:. Is there anyone else that I am missing? ]
>

Not that I can think of.


> Just a short notice that I am currently working on making llvm-dwarfdump
> more developer friendly. There are quite a few features in Darwin’s
> dwarfdump that we find quite useful and that we would like to contribute to
> llvm-dwarfdump.
>

Generally sounds good


>
> I have started by augmenting the -debug-dump=info output:
>  - Symbolic names for attribute values
>  - Line table lookups for DW_AT_decl_file
>  - Annotate DW_AT_specification with the target DIE’s name
>

I'm wondering if we could generalize this somehow (DW_AT_specification is
not the only cross-DIE reference (DW_AT_type, DW_AT_abstract_origin come to
mind but there are others too, of course)).

One of my motivations to consider this was to get more dif-able dwarfdump
output (currently, having the fixed byte offsets in the output means even a
small change in output (adding an attribute) changes all the offsets and
makes diff not terribly legible). Even further than that, would be the
possibility of output in an order not dictated by the file, but by some
canonicalization - that way output between clang and GCC might be diffable
(but that's really hard - if you have two DW_TAG_foo in a list of children,
which one do you put first? Do you try to find the name and sort by that?)


>  - DWARF expression pretty-printing
>

For DWARF 4 I think there's a DW_FORM_exprloc that is really just a
DW_FORM_data with the semantic hint that "this is a DWARF expression",
precisely (so far as I can tell) so that tools like this don't have to be
smart about which attribute this DW_FORM_data is for (and whether it's
probably an expression based on that information), and instead just use the
form code alone.

Though I realize you'll need pre-4 support, so I guess that involves having
a list of the attributes (DW_AT_*) that have expression values and checking
for that, rather than just the form code.


>
> With these enhancements, the debug_info dump is nearly always sufficient
> and the user rarely needs to go and decode himself the referenced content
> of other debug sections.
>

It'd be great to see at least some example test case improvements as you
add these features (& perhaps a brief summary of "preferred testing idioms"
in the commit message or elsewhere so we can try to raise the bar for
future test cases as you make these improvements).


>
> There will be more work by me going on in llvm-dwarfdump/libDebugInfo
> these coming weeks.
> I’ll start sending patches to llvm-commits later today.
>

Looking forward to it.


>
> Cheers,
> Fred
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140903/837a7930/attachment.html>


More information about the llvm-dev mailing list