[lldb-dev] Frame documentation

[Enrico Granata]

> On Dec 2, 2014, at 4:44 PM, Jose H <jose.francisco.hevia at gmail.com> wrote:
> 
> So for generating this Data Model we load the frame variable parent*
> as an SBValue, we dereference the pointers with each of their
> children, now we continue with each children and we find the reference
> to the parent again, so if we continue it will never end, and the
> three will be infinite.
> 
> So for every reference I need some way of looking at the other
> references in the in process tree, and if already there stop there.
> 
> But I suppose the people of lldb faced this problem before I did and
> you have already solved it somehow. Did you?
> 


If I understand your concern, you’re asking how we deal with situations like this:

class Foo {
Foo* next;
};
// … code ...
Foo foo;
foo.next = &foo;

where there is a back-reference chain, and you would essentially end up navigating forever

The solution that LLDB uses is actually quite simple. We have a concept of “pointer depth”, i.e. you can tell the debugger how many levels of pointers one should traverse. If, for example, you set it to 2, you would get

foo
    foo.next
                 foo.next
                             unexpanded pointer

In a graphical environment, you could only turn down pointers at explicit user request (imagine a turndown like Xcode’s Variables View has). Then, sure, the user can keep turning down, but it’s not an infinite self-hanging loop, it’s an action-reaction feedback with constantly identical-yet-deeper reactions.

Or, of course, you could get really fancy, and store pointers as you encounter them, and refuse to expand anything you expanded, maybe providing a visual “back up” arrow that tells you you’re in a reference loop.

Thanks,
- Enrico
📩 egranata@.com ☎️ 27683




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141202/03353408/attachment.html>