> On Dec 2, 2014, at 4:44 PM, Jose H <jose.francisco.he...@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
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
