[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
correct.

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
them.

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
flag.

- 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