<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 3, 2014 at 9:30 AM, Frédéric Riss <span dir="ltr"><<a href="mailto:friss@apple.com" target="_blank">friss@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
[ I think I put the most important contributors to the DebugInfo stuff in Cc:. Is there anyone else that I am missing? ]<br></blockquote><div><br></div><div>Not that I can think of.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote><div><br></div><div>Generally sounds good</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I have started by augmenting the -debug-dump=info output:<br>
 - Symbolic names for attribute values<br>
 - Line table lookups for DW_AT_decl_file<br>
 - Annotate DW_AT_specification with the target DIE’s name<br></blockquote><div><br></div><div>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)).<br>
<br>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?)<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 - DWARF expression pretty-printing<br></blockquote><div><br>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.<br>
<br>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.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
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.<br></blockquote><div><br>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).<br>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
There will be more work by me going on in llvm-dwarfdump/libDebugInfo these coming weeks.<br>
I’ll start sending patches to llvm-commits later today.<br></blockquote><div><br></div><div>Looking forward to it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Cheers,<br>
Fred</blockquote></div><br></div></div>