[PATCH] D28303: Add iterator support to DWARFDie to allow child DIE iteration.

Adrian Prantl via llvm-commits llvm-commits at lists.llvm.org
Thu Jan 5 13:20:40 PST 2017


> On Jan 5, 2017, at 1:16 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> On Thu, Jan 5, 2017 at 12:38 PM Greg Clayton <clayborg at gmail.com> wrote:
>>> On Jan 5, 2017, at 11:33 AM, David Blaikie <dblaikie at gmail.com> wrote:
>>> 
>>> Looks like it might be missing test coverage for the "skip null" in the iterator ctor.
>> 
>> I have added a test for this that I’ll post in the next diff.
>> 
>>> Also - I'd like a good sense of what's going to happen with the child iteration inconsistency between this and the getChild/Sibling API before this is committed.
>> 
>> DWARFDie::getSibling() will still return a NULL DIE at the end. Iteration won’t. What are you suggesting happen?
>> 
>> We could add a bool to the getSibling() API:
>> 
>> DWARFDie DWARFDie::getSibling(bool IncludeNull = false);
>> 
>> Then we could get rid of the code in DWARFDie::iterator and have it call DWARFDie::getSibling() with false. The DWARFDie::dump would call it with true. 
>> 
>> Am I missing something? Let me know what you were thinking.
> 
> Mostly I was hoping/thinking/suggesting removing the null DIEs as you'd suggested previously.
> 
> It's only a couple of places - one in obj2yaml and one in dwarfdump, yes? It doesn't seem worth complicating the libDebugInfo APIs for those two use cases, I think?
> 
> Adrian - any thoughts/preferences here?

Removing the NULL DIEs make computing the offsets for printing in dwarfdump more complicated but it does save about 50MB when parsing something the size of clang. I would like to defer to Greg here since he actually looked at much work / extra overhead that would be.

-- adrian


More information about the llvm-commits mailing list