[lldb-dev] frame variable command, child objects, depth limits

Bruce Mitchener bruce.mitchener at gmail.com
Tue Jun 24 18:06:07 PDT 2014

On Wed, Jun 25, 2014 at 2:39 AM, Enrico Granata <egranata at apple.com> wrote:

> On Jun 24, 2014, at 9:56 AM, Bruce Mitchener <bruce.mitchener at gmail.com>
> wrote:
> The frame variable command doesn't seem to obey printing depth limits,
> instead having a '-D' parameter that defaults to unlimited / infinity.
> Bruce,
> I am not sure what “printing depth limits” you mean, if not the -D flag.
> If that flag’s value is not honored, we should probably fix it. If you
> mean something else, can you elaborate a little bit more?

I meant the pointer depth limits aren't being obeyed (but I'm also not
using pointers). The explanation from Greg in his response to my email was

The -D flag does work.

In the Dylan language implementation, we have objects that refer to
> themselves regularly (example is an empty list is a pair, head and tail,
> each of which points to the empty list). There are plenty of other
> situations where this happens.
> Is this done via pointers? And do you expose them as such? If so, the
> —ptr-depth would be the flag to use

Well, due to other issues (like the thread we have going on the commits
list), I'm unable to use pointers. I've modified our run-time to instead
represent Dylan values as uintptr_t so that I can have synthetic types for

I thought that perhaps I would just set a different default when loading my
> scripts, but there doesn't seem to be a setting for the depth parameter to
> "frame variable".
> No, but it would be interesting to have a way to set default arguments to
> commands - We don’t have that feature yet though

It seems like just having a process or global setting here might be useful?

Right now, if we just run "frame variable" while debugging a Dylan app,
we're pretty much guaranteed to hang LLDB.  We have to always pass a -D

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

More information about the lldb-dev mailing list