[PATCH] D28040: Don't store the NULL DIEs in the DIE array in the DWARFUnit.

David Blaikie via llvm-commits llvm-commits at lists.llvm.org
Wed Jan 4 09:52:18 PST 2017


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.

But not a huge deal either way.

On Tue, Jan 3, 2017 at 3:31 PM Greg Clayton via Phabricator <
reviews at reviews.llvm.org> wrote:

> clayborg abandoned this revision.
> clayborg added a comment.
>
> 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
> 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.
>
> So in order to not ruin the accurate representation that we currently have
> I will leave the NULL dies in.
>
>
> https://reviews.llvm.org/D28040
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170104/c32765d8/attachment.html>


More information about the llvm-commits mailing list