<div dir="ltr">I'd still vote in favor of removing them, FWIW - I tend to think of the DWARF parsing APIs as providing the semantics of the data first, and fidelity second - if producing bit-for-bit identical output from DWARF is a bit more work (such as for obj2yaml and dwarfdump) but walking the data structures to extract semantically meaningful information that the DWARF is describing is easier, I tend to think that's the right tradeoff.<br><br>But not a huge deal either way.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jan 3, 2017 at 3:31 PM Greg Clayton via Phabricator <<a href="mailto:reviews@reviews.llvm.org">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">clayborg abandoned this revision.<br class="gmail_msg">
clayborg added a comment.<br class="gmail_msg">
<br class="gmail_msg">
There are test failures with the obj2yaml and yaml2obj. After thinking about this patch more, we should probably leave in the NULL DIEs. My reasoning is<br class="gmail_msg">
the NULLs correctly show the structure of the DWARF without needing any magic to reconstruct the NULL dies like we needed to do when dumping the DWARF. This was easy to work around for the dumping since we were using the getFirstChild()/getSibling() calls, but other clients that just want to walk through the DWARFDebugInfoEntry array, like the obj2yaml, would need to magically reconstruct these extra NULL dies with the correct offset.<br class="gmail_msg">
<br class="gmail_msg">
So in order to not ruin the accurate representation that we currently have I will leave the NULL dies in.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<a href="https://reviews.llvm.org/D28040" rel="noreferrer" class="gmail_msg" target="_blank">https://reviews.llvm.org/D28040</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div>