<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 6, 2014 at 11:19 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"><br><div><span class=""><blockquote type="cite"><div>On Sep 30, 2014, at 5:43 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:</div><br><div><br><br style="font-family:Helvetica;font-size:12px;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:Helvetica;font-size:12px;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 Thu, Sep 4, 2014 at 8:53 AM, Frédéric Riss<span> </span><span dir="ltr"><<a href="mailto:friss@apple.com" target="_blank">friss@apple.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"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On 04 Sep 2014, at 17:40, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 4, 2014 at 8:32 AM, Frédéric Riss<span> </span><span dir="ltr"><<a href="mailto:friss@apple.com" target="_blank">friss@apple.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"><div style="word-wrap:break-word"><br><div><div><blockquote type="cite"><div>On 04 Sep 2014, at 17:19, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 4, 2014 at 6:55 AM, Frederic Riss<span> </span><span dir="ltr"><<a href="mailto:friss@apple.com" target="_blank">friss@apple.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">Hi dblaikie, echristo, aprantl,<br><br>This is the merge of 2 patches:<br><br>Pass the DWARFUnit to DWARFDebugLine::getFileNameByIndex().<br><br>This way it can query the compilation dir when it is referenced (when a file references directory index 0, it refers to the compilation dir).<br></blockquote><div><br></div><div>Alternatively (Though not necessarily better - open to opinions/preferences) DWARFUnit could have a wrapper for getFileNameByIndex and could be returned a zero/default/something that the DWARFUnit could detect and return the CU.<br><br>Or the DWARFDebugLine could be constructed with its unit, or just with the comp_dir of its unit so it didn't have to be passed in/queried for on every lookup?</div><div><br></div></div></div></div></div></blockquote><div><br></div></div><div>I’m currently working on an alternative where I turn DWARFContext.cpp::getFileNameForUnit() and getFileLineInfoForCompileUnit() into LineTable methods. This way I reduce code duplication with what I’ve added to DWARFDebugInfoEntry::dump. I’ll see how that turns out.</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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"><br>and:<br><br>[dwarfdump] Implement extraction of file information referenced in .debug_info.<br><br>This patch pretty prints the contents of the DW_AT_decl_file, DW_AT_call_file, DW_AT_decl_line and DW_AT_call line attributes.<br>Drop the const on the passed DWARFUnit to be able to call getLineTableForUnit (the line table construction is lazy, thus the getter might modify the Unit).<br></blockquote><div><br></div><div>What pretty printing occurs for lines? (obviously for files this would allow you to print the file name rather than the file number - but DW_AT_decl/call_line already contain the line number, right?)</div></div></div></div></blockquote><div><br></div></div><div>It’s just that they’re printed as decimal numbers. Which is indisputably more pretty for line numbers :-)</div></div></div></blockquote><div><br></div><div>Agreed - though should we just print numbers as decimal generally? Which numbers benefit from being printed as hex I wonder?<br></div></div></div></div></div></blockquote><div><br></div></span><div>All unsigned Forms get printed as hex by FormValue. As this covers addresses for example, I wouldn’t call that a bad choice. In fact, I can’t come up right now with another attribute I’d like to see printed as decimal (but I’m sure there are some).</div></div></div></blockquote><div><br></div><div>You can probably add DW_AT_lower_bound, DW_AT_upper_bound, and DW_AT_count to the list of attributes that might make more sense as (signed) decimal. (just something I came across in a test case)</div></div></div></blockquote><div><br></div></span><div>Are you sure about the (signed) part? I have been working on a patch to add this, but now I’m wondering… What makes it a signed entity, I’m not seeing anything in the standard that mandates it. It’s not a big deal because anything we generate should be OK, but I thought I’d ask before submitting the pacth (which is actually not that obvious as we don’t have getAsSignedConstant() right now, and getting that tested isn’t that easy).</div></div></div></blockquote><div><br></div><div>Well count would be unsigned, but upper & lower bound can be negative - apparently fortran has user-specified array bounds, so you can have an array with indices [-5, 5] for example, as far as I understand it (which is not very far at all - so I'm happy to be corrected)<br><br>FWIW - GCC seems to produce an upper bound of 0xffffffff (or whatever it is - max 32 or 64 bit int) for arrays of unknown bound (flexible array members in c99) or arrays of zero length. I'm not sure what the right way to render that is, but -1 /might/ be nicer than MAX_UINT. That's the only case I've seen in person, the Fortran case is something I know about only in the abstract/according to the DWARF spec.<br><br>(arguably all these things should use FORM_sint/uint or whatever they're called, so they communicate the kind of representation they're using - it's just when they use the old _dataN (which I think GCC still does for the upper_bound of unknown/zero size that I mentioned) that we have to choose a sensible default)</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><div><br></div><div>Fred</div><span class=""><br><blockquote type="cite"><div><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;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"><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"><div><span><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>(might be worth splitting the line number part of the patch out - it might be easier (as you say, it's simply printing them as decimal rather than hex - doesn't depend on access to the line table you're adding here, etc) or it might be harder/different (if we end up changing the default & trying to decide if there are places where that new default would be problematic, etc))</div></div></div></div></blockquote><div><br></div></span><div>I’ll do that once I finish the current rework.</div><div><br></div><div>Fred</div><span><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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"><div><div><br></div><div>Fred</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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"><br><a href="http://reviews.llvm.org/D5192" target="_blank">http://reviews.llvm.org/D5192</a><br><br>Files:<br> <span> </span>lib/DebugInfo/DWARFContext.cpp<br> <span> </span>lib/DebugInfo/DWARFDebugInfoEntry.cpp<br> <span> </span>lib/DebugInfo/DWARFDebugInfoEntry.h<br> <span> </span>lib/DebugInfo/DWARFDebugLine.cpp<br> <span> </span>lib/DebugInfo/DWARFDebugLine.h<br> <span> </span>test/DebugInfo/X86/2011-09-26-GlobalVarContext.ll<br> <span> </span>test/DebugInfo/X86/fission-cu.ll<br> <span> </span>test/DebugInfo/namespace.ll<br> <span> </span>test/MC/MachO/gen-dwarf.s</blockquote></div></div></div></blockquote></div></div></div></blockquote></div></div></div></blockquote></span></div></div></blockquote></div></div></blockquote></span></div><br></div></blockquote></div><br></div></div>