<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 5, 2014 at 11:56 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"><div style="word-wrap:break-word"><div><div class="h5"><br><div><blockquote type="cite"><div>On 05 Sep 2014, at 20:05, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:</div><br><div><br><br style="font-family:Menlo-Regular;font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Menlo-Regular;font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote" style="font-family:Menlo-Regular;font-size:11px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Fri, Sep 5, 2014 at 10:39 AM, Robinson, Paul<span> </span><span dir="ltr"><<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank">Paul_Robinson@playstation.sony.com</a>></span><span> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>> > 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></div></div></div></blockquote></div><div><br></div></div></div>I totally agree with that point of view. I also can understand Paul’s opinion. Nothing prevents us from having a —verbose or —raw option that avoids all the shortcuts and displays the naked debug info. But again, be it for testing or human consumption, I think the prettified output is (nearly always) better.</div></blockquote><div><br></div><div>Agreed - even for the existing line table situation, I think I'm going to run up against a need to dump the actual state machine eventually. But we'll cross that bridge when we come to it - and add pieces of "raw" output mode as we need them.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>Fred<br><div><br></div></div></div></blockquote></div><br></div></div>