[LLVMdev] llvm-dwarfdump improvements

[Frédéric Riss]

> On 03 Sep 2014, at 18:41, David Blaikie <dblaikie at gmail.com> wrote:
> 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)).

The patches I have cover at least AT_type, but in a slightly different way. For specification and abstract_origin, I dump the target name, for AT_type, I try to construct a representative type name. But we’ll discuss the specificities once I drain my patch queue down to the one doing the type printing.

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

This allows to match simple types and specifications without having to play regex games with FileCheck. I’m not sure we get closer to an easily diff-able output, but suggestions are welcome.

> 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?)

One of the features I want to port is a search command line interface. This allows to at least reduce the scope of the dump to an interesting subtree. But your suggestion is much more ambitious. Again, suggestions welcome :-)

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

Yes. But we can have the attribute matching and then test exprloc besides that (Don’t know if this would get us anything).

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

I haven’t really focused on that, I just made the tests pass. But let’s see in the patch reviews if the format suits you and if it allows to actually simplify test writing. To be honest, the primary objective of doing this work was for me to improve the dump human-readability, but let’s see if we can improve FileCheck testing along the way.

Fred

> 
> 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/d91cab81/attachment.html>