0

ALL,

Consider following class structure:

class Base -> class public Derived1 -> class public Derived2.

I.e. there is a Base class. Class Derived1 is a direct child of Base and class Derived2 is a direct child of Derived2, but not not Base.

Is there a way in LLDB to see the class structure?

I'm trying to debug my program with LLDB on OSX and having difficulty seeing the class tree for a variable.

I tried to do:

> p (Derived1 *) this

but it did not help - it just showed the same (Derived2) class and its address in the output.

Thank you.

EDIT:

Trying

v *this

results in:

(lldb) v *this
error: the version command takes no arguments.
(lldb)

EDIT2:

This is what I get:

Igors-MacBook-Air:Debug igorkorot$ lldb
(lldb) version
lldb-902.0.79.7
  Swift-4.1
(lldb)
Igor
  • 5,620
  • 11
  • 51
  • 103

1 Answers1

0

lldb by default shows the object resulting from an expression evaluation using its full dynamic type. That's done as part of the "value printer" that formats up the result after the expression has been evaluated.

The result of your expression was an object pointer whose static type was Derived1 (because you cast it), but whose vtable pointer pointed to the Derived2 vtable, indicating that it's full dynamic type was Derived2, which is how lldb printed it.

That's actually pretty handy in general. For instance, if you are in a method of Base, but this is really a Derived2, you usually want to see the full object, not just the Base part.

You can turn off dynamic type resolution using:

(lldb) expr -d no-dynamic-values -- (Derived *) this

Also, if you ask lldb to show you an object rather than an object pointer, lldb will show it organized by the class hierarchy, with the base classes nested in their parents, and the ivars for each subclass nested in their owning class. So for instance:

(lldb) v *this

will I think show you what you are looking for.

Jim Ingham
  • 25,260
  • 2
  • 55
  • 63
  • I guess you meant `p *this`. Problem is - it does show a hierarchy, but it gives me variable (member) names without the types and the original object is not being up/down-casted. I have couple of objects and I need to understand where is the problem on calling the virtual function. And so I need to see the type tree of the object. – Igor Jul 02 '21 at 05:39
  • No, I meant `v`. For viewing stack locals and the like, `v` is a much more efficient command. If you want to see types of sub-elements, pass the `-T` argument to `v` or use `expr -T --`. Using dynamic types you shouldn't need up-casting, it will show the full type so there's nothing up to cast it to. If you want to downcast, then use -no-dynamic-values. – Jim Ingham Jul 06 '21 at 17:12
  • BTW, if what you want to see is the vtable for your object, know that lldb doesn't print that as part of the object. For the most part folks didn't want to have to look past that every time they inspected an object, so it wasn't in the original variable printing. There should be some other command that will show you this, but it doesn't exist yet. – Jim Ingham Jul 07 '21 at 00:05
  • do you know how can I debug from Xcode? When I try it fails immediately with the exception from the `dylib` loading in some assembly code. Even before the application starts. I did make a script to copy them to the `Application Bundle`. But I think Xcode expects them somewhere else. – Igor Jul 07 '21 at 01:00
  • please see my edit. Apparently `v` is for version. – Igor Jul 09 '21 at 02:30
  • A couple of years ago lldb added `v` as an alias for `frame variable`. lldb prioritizes exact matches when looking up commands, so the single character "v" resolves to the `v` alias, not the `version` command. If you are using an older lldb, you might not have this alias, however. – Jim Ingham Jul 09 '21 at 18:34
  • That is a fairly old lldb, the current released version is 1205. `v` is a convenience alias for `frame var`, so with your lldb you can either make a `v` alias with `command alias` or use `frame var`. – Jim Ingham Jul 12 '21 at 16:39