<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 5, 2014 at 10:39 AM, Robinson, Paul <span dir="ltr"><<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank">Paul_Robinson@playstation.sony.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> > The realpath piece of this is particularly interesting - I don't know<br>
> > what that API is, where it comes from (why it might not always be<br>
> > available), etc. Also, not sure it makes sense to canonicalize the paths<br>
> > based on the actual filesystem, rather than just rendering what's in the<br>
> > line table... maybe some examples would help me understand better. (is<br>
> > that codepath tested? How do we test it on machines that don't have<br>
> > realpath?)<br>
><br>
> I knew this bit would attract some interest. Regarding the availability,<br>
> there is a configure test, thus I suppose it’s not available everywhere<br>
> (Windows maybe?). It really helps the legibility when you have projects with<br>
> deep, recursive, build trees. For example, instead of <br>
><br>
> "/tmp/build/some/project/with/very/deep/source/tree/../../../../../../../../some/project/with/very/deep/source/tree/foo.c”<br>
><br>
> you get<br>
><br>
> “/tmp/some/project/with/very/deep/source/tree/foo.c"<br>
><br>
> Note however that this part is optional and could be discussed separately.<br>
> Another motivation for me to have this in llvm-dwarfdump is that Darwin’s<br>
> dwarfdump does this transformation. You might not care, but having nearly<br>
> identical outputs allows me to cross-verify the 2 implementations on a very<br>
> large set of archived binaries. I think this gets us more coverage that any<br>
> LIT tests that we might add. I understand however that this is in no way a<br>
> strong argument for getting it into the tree, I just thought I’d mention the<br>
> validation I do on the side.<br>
<br>
</span>My understanding is that llvm-dwarfdump is a tool to help testing LLVM, while<br>
Darwin's dwarfdump is a tool to help users understand their object files.<br></blockquote><div><br></div><div>I don't think the use cases are so distinct. Most of the people who care about the exact DWARF that's produced either work on debug info producers (probably LLVM, in this instance) or consumers, and most of the time ease of reading the semantics expressed by the debug info is sufficient.<br><br>For example, our line table dumping doesn't dump the line table state machine, just the resulting table that was generated from that state machine.<br><br>In this instance I just wanted to check whether this code was testable - especially if we are going to move to a situation where llvm-dwarfdump is a more widely used tool, it seems prudent to ensure the testing is high quality (to be honest, the current testing, as this is a test tool, has been hit-and-miss (because it basically devolves to "checkin some known dwarf in an object file and run that through dwarfdump to inspect the output" - and we don't always bother with that))</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would rather have a testing tool show me exactly what's in the object file,<br>
rather than do user-friendly transformations that hide (some part of) the<br>
exact contents of the file.<br>
(Annotating the output, which you have been doing such a great job on--thanks!--<br>
is fine; that's different from hiding things that are actually in the file.)<br>
<br>
It shouldn't be hard to pipe llvm-dwarfdump output through a filter that could<br>
address the ../.. part, which would still give you good comparability to the<br>
output of dwarfdump.<br>
Thanks,<br>
--paulr<br>
<br>
</blockquote></div><br></div></div>