[lldb-dev] Frame documentation

[Greg Clayton]

> On Dec 2, 2014, at 4:44 PM, Jose H <jose.francisco.hevia at gmail.com> wrote:
> 
> Wow!! Greg, this is simple an incredible answer. Very useful
> information, thank you again.
> 
> I was scrapping little bits of the information you have posted on your
> mail on my own, but it is way more clear now. It will take a while for
> me to process all this information.
> 
> One of the things I realized about variables is that they are not a
> hierarchy but a network. So in order to make a graphical treeview that
> in independent of the back end code it seems I need to do little
> tricks.
> 
> Imagine we have an structure parent, parent references children, but
> each children also references their parent, so we have circular
> references or loop references.

That is fine. You don't auto expand anything in your view (or you can, but you should stop at pointers or references). If you don't auto expand anything, then your users will do so by clicking to expand the tree view item and they can expand as much as they want to. 

"frame variable" will print children or structs, unions and classes, but pointers and references don't get expanded for this very reason.

> 
> The same could happen if we use double linked chain list , with each
> node pointing to next node but also to the last one.

Again, don't expand pointers and references and you are ok.

> 
> Now I want to represent the hierarchical structure of the variables in
> a DataSource(the model of the data in a ModelViewContoller design)
> that a viewcontroller is going to represent in the GUI. The
> viewcontroller knows nothing about SBData or any other lldb code,
> which makes porting(and maintaining) to other GUIs like Qt later much
> easier.
> 
> 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.

Just don't auto expand ptrs and refs.
> 
> 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.

Most GUIs will just show the top level variables and not even expand structs, unions and classes unless the use clicks on a disclosure triangle. Try loading the lldb/examples/python/lldbtk.py file:

(lldb) file a.out
(lldb) b main
(lldb) run
(lldb) command script import /users/me/lldb/examples/python/lldbtk.py
(lldb) tk-variables 


Not the pointers haven't been expanded. You can probably loot the python code in lldbtk.py and make it work with your GUI framework.

> But I suppose the people of lldb faced this problem before I did and
> you have already solved it somehow. Did you?

Yep, GUIs don't expand anything unless the user clicks to expand it. Below I clicked on the triangle before "path" to expand it:


> 
> Anyway,like with Frankenstein, the thing is finally taking shape and
> soon will get alive. The possibilities lldb bring look out of this
> world. Dreams like creating a video of the evolution of data
> structures while the program become possible, making possible to see
> your program from other perspectives and using parts of your brain
> that monotone text atrophies is within reach now, something you could
> almost touch now.

Hopefully my comments shed some light on things above?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141203/0125c78c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: variables.png
Type: image/png
Size: 51813 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141203/0125c78c/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: expanded.png
Type: image/png
Size: 57760 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141203/0125c78c/attachment-0001.png>