
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 05 Sep 2014, at 20:18, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="">dblaikie@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br style="font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Menlo-Regular; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><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; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Fri, Sep 5, 2014 at 12:47 AM, Frédéric Riss<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:friss@apple.com" target="_blank" class="">friss@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><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;"><div style="word-wrap: break-word;" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On 05 Sep 2014, at 00:28, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank" class="">dblaikie@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">Please go ahead & commit the decl/call_line portion of this (I'll take your word for it that these seem like the only ones that should be printed as decimal, the rest as hex - and if we see other cases we can figure it out at that point) & then rebase this patch.<br class=""></div></div></blockquote><div class=""><br class=""></div></span><div class="">This is r217232, thanks.</div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">The realpath piece of this is particularly interesting - I don't know what that API is, where it comes from (why it might not always be available), etc. Also, not sure it makes sense to canonicalize the paths based on the actual filesystem, rather than just rendering what's in the line table... maybe some examples would help me understand better. (is that codepath tested? How do we test it on machines that don't have realpath?)</div></div></blockquote><div class=""><br class=""></div></span><div class="">I knew this bit would attract some interest. Regarding the availability, there is a configure test, thus I suppose it’s not available everywhere (Windows maybe?).</div></div></div></blockquote><div class=""><br class=""></div><div class="">Is that configure property available to lit, so we could write tests that demonstrate that the functionality is actually working when the feature is available? (specifically by comparing the line table entry (which will still have the ../../../ stuff) and the processed name in the DIE dump) (& demonstrate that, in the absence of the feature, we get the (degraded) expected/correct output too)<br class=""></div></div></div></blockquote><div><br class=""></div>I have no idea if the configure results are available in some other form that the preprocessor macros in Config.h. I get your point about the testing, but I’m a bit at a loss about how to implement it. Especially considering that these will be llvm tests: the paths need to exist for realpath to resolve them, but the llvm tests usually embed static paths in the IR.<br class=""><br class=""><blockquote type="cite" class=""><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; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="">Might be worth adding it as a feature in lit - so far as I understand it's not too expensive to do so. NOt sure if you have to plumb a separate negative feature through so you can write tests targeted for platforms that lack the feature separately.</div></div></blockquote><div><br class=""></div><div>How do you expect lit to expose the availability of the feature? Some syntax that would skip the test if the feature is not available? </div><div><br class=""></div><div>Fred</div><div><br class=""></div><blockquote type="cite" class=""><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; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><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;"><div style="word-wrap: break-word;" class=""><div class=""><div class="">It really helps the legibility when you have projects with deep, recursive, build trees. For example, instead of </div><div class=""><br class=""></div><div class=""><div style="margin: 0px;" class=""><div style="margin: 0px;" class="">"/tmp/build/some/project/with/very/deep/source/tree/../../../../../../../../some/project/with/very/deep/source/tree/foo.c”</div><div style="margin: 0px;" class=""><br class=""></div><div style="margin: 0px;" class="">you get</div><div style="margin: 0px;" class=""><br class=""></div><div style="margin: 0px;" class="">“/tmp/some/project/with/very/deep/source/tree/foo.c"</div></div></div><div class=""><br class=""></div><div class="">Note however that this part is optional and could be discussed separately.<span class="Apple-converted-space"> </span></div></div></div></blockquote><div class=""><br class="">That might be worthwhile.<br class=""> </div><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;"><div style="word-wrap: break-word;" class=""><div class=""><div class="">Another motivation for me to have this in llvm-dwarfdump is that Darwin’s dwarfdump does this transformation. You might not care, but having nearly identical outputs allows me to cross-verify the 2 implementations on a very large set of archived binaries. I think this gets us more coverage that any LIT tests that we might add. I understand however that this is in no way a strong argument for getting it into the tree, I just thought I’d mention the validation I do on the side.</div><div class=""><br class=""></div><div class="">Fred</div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Sep 4, 2014 at 2:37 PM, Frederic Riss<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:friss@apple.com" target="_blank" class="">friss@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><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;">Sorry for the spam. I'm still learning to use arcanist, and I must say at this point it's more a burden that a help... This latest revision is the result of a small series of 3 commits that should be easy enough to distinguish. They aren't really intermingled except for the test updates.<br class="">The first just prints the line numbers in decimal and updates the tests.<br class="">The second moves some static helpers of DWARFContext.cpp into equivalent methods of LineTable. There should be no functional change though.<br class="">The third one uses the newly exposed method to find and print full names for files referenced by DW_AT_(decl|call)_file.<br class=""><br class=""><a href="http://reviews.llvm.org/D5192" target="_blank" class="">http://reviews.llvm.org/D5192</a></blockquote></div></div></div></blockquote></span></div></div></blockquote></div></blockquote></div><br class=""></body></html>