Bruce, your patch seems to essentially implement the algorithm "display children of pointer types if within the pointer depth OR there is a formatter that wants them shown"
That's somewhat worrisome. The reason for having a pointer depth is that pointers potentially introduce recursion - i.e. you can have a pointer that points to itself. Limiting how deep you look into pointer values has the benefit that lldb will not hang in such situations trying to display an i infinitely recursive structure - which is especially useful if the infinite recursion was accidental and unexpected. I am a little worried about getting lldb in a state in which by default it might attempt to endlessly recurse into pointers. There is a similar problem with Cocoa structures, e.g. NSArray*. Since it comes out as a pointer, it doesn't get expanded by default and the user needs to pass a --ptr-depth flag to get synthetic children to show up. This is not an issue in graphical IDEs (Xcode for instance) since there the user has to explicitly "twist open" variables with a gesture that is akin to passing that flag. If we were to start expanding pointer chains automatically and with no hard limit on depth, a recursion detector would be in order (have I seen this same pointer value in this chain yet? yes - then stop) Even that would not be a perfect solution of course (a garbage pointer could have many many many levels of depth to be followed before you run into the same value or unreadable memory). To truly make this work, you would need code that at any level of depth answers the question "is this a valid and yet unseen object pointer that I should expand?" - synthetic providers could be expanded to try and answer that question, but it's not anywhere near easy to answer it in any interesting case (look around for heuristics that try to validate STL containers :-). tl;dr it might be easier/safer to change typedefs in your code to non-void* things than make lldb auto-expand pointers Sent from my iPhone > On Jun 22, 2014, at 8:08 AM, Bruce Mitchener <[email protected]> > wrote: > > The attached patch addresses an issue that I had when writing synthetic > providers for the Dylan language's C back-end and run-time. > > In our code currently, all values are: > > typedef void* dylan_value; > > dylan_value is a tagged pointer and so we use it to represent all of our > objects. I have a synthetic provider that works to provide children where > appropriate (like vectors). Unfortunately, they don't show up. > > As a workaround, I'm looking at converting our codebase to use: > > typedef uintptr_t dylan_value; > > With that, or the attached patch, everything works out fine. (Well, there's a > separate bug with ToT, but I'll bring that up later.) > > Please consider the attached patch. > > - Bruce > > <0001-Fix-having-a-synthetic-child-of-a-pointer.patch> > _______________________________________________ > lldb-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits _______________________________________________ lldb-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
