<div dir="ltr">2.13.2 says:<br><br>"A debugging information entry that represents a declaration that completes another (earlier) non-defining declaration may have a DW_AT_specification attribute whose value is a reference to the debugging information entry representing the non-defining declaration"<br><br>Seems pretty clear that there's only one defining declaration and that DW_AT_specification is for referencing from that defining declaration to the non-defining declaration.<br><br>And the wording around abstract origins I think is pretty clear too - that there's a concrete definition, an abstract definition, and any number of inline definitions.<br><br>But as always, real world situations somewhat trump any of this, imho - so if there's a compelling use case/existing producer that produces some interesting DWARF related to declarations/definitions specifications/abstract_origins, it'd be great to see to better understand what would be useful to support (& to document why it's being supported/what to look for when we're evaluating how that support should work/be maintained in the future)</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Feb 13, 2018 at 11:42 AM Jonas Devlieghere <<a href="mailto:jdevlieghere@apple.com">jdevlieghere@apple.com</a>> wrote:<br></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;line-break:after-white-space">Is there anything in the DWARF standard that would suggest this shouldn’t be possible? If not I think we should support it as is and implement the more advanced loop detection?</div><div style="word-wrap:break-word;line-break:after-white-space"><br><div><br><blockquote type="cite"><div>On Feb 9, 2018, at 3:53 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:</div><br class="m_2493106059732355511Apple-interchange-newline"><div><div dir="ltr">*nod* Thought so - would be good to know what scenario this is meant to support.<br><br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 9, 2018 at 2:22 AM Jonas Devlieghere via Phabricator <<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">JDevlieghere added a subscriber: clayborg.<br>
JDevlieghere added a comment.<br>
<br>
In <a href="https://reviews.llvm.org/D43092#1002677" rel="noreferrer" target="_blank">https://reviews.llvm.org/D43092#1002677</a>, @dblaikie wrote:<br>
<br>
> Could you check the revision history here? I'm pretty sure the first version of this I reviewed from Greg wasn't recursive - and then it became recursive at some point to handle something needed, but maybe those decisions need to be reexamined?<br>
<br>
<br>
It was @clayborg himself that updated the implementation. (<a href="https://reviews.llvm.org/D40156" rel="noreferrer" target="_blank">https://reviews.llvm.org/D40156</a> <a href="https://reviews.llvm.org/rL319104" rel="noreferrer" target="_blank">https://reviews.llvm.org/rL319104</a>)<br>
<br>
> The previous implementation would only look 1 DW_AT_specification or DW_AT_abstract_origin deep. This means DWARFDie::getName() would fail in certain cases. I ran into such a case while creating a tool that used the LLVM DWARF parser to generate a symbolication format so I have seen this in the wild.<br>
<br>
<br>
<a href="https://reviews.llvm.org/D43092" rel="noreferrer" target="_blank">https://reviews.llvm.org/D43092</a><br>
<br>
<br>
<br>
</blockquote></div></div>
</div></blockquote></div><br></div></blockquote></div>