Most C++ classes and C structs don't have data formatters, particularly not
classes that you write yourself.
The way value printing works in lldb is that we start by making the ValueObject
for the value from its Type, so at that stage it is just a direct view of the
members of the object. That is done without help of the data formatters,
reading instead directly from the object's type. Then we consult our type
match -> summary/synthetic children registries and we construct a summary or a
set of "synthetic children" (or both) for the object if we find any matches
there. Then the ValueObjectPrinter prints the object using the Type based
ValueObject, the Summary and the Synthetic Children, and there's a print
options object that says whether to use the raw view, the summary and/or the
synthetic children.
But for a type lldb knows nothing about, there won't be any entries in the
formatter maps, so you should just see the direct Type based children in that
case.
--raw sets the right options in the print option object to get the printer to
just use the strict Type based view of the object, with no formatters applied.
In your case, you used "Class" as your type name and Class is a special name
in ObjC and there happens to be a formatter for that. You can always figure
out what formatters apply to the result of an expression with the "type
{summary/synthetic} info" command. For your example, I see (my variable of
type Class was called myClass):
(lldb) type summary info myClass
summary applied to (Class) myClass is: (not cascading) (hide value) (skip
pointers) (skip references) Class summary provider
(lldb) type synthetic info myClass
synthetic applied to (Class) myClass is: Class synthetic children
On macOS those summary/synthetic child providers are in the objc category. The
info output should really print the category as well, that would be helpful.
But you can do "type summary list" and then find the summary in that list and
go from there to the category. Ditto for "type synthetic".
What do you get from that?
Jim
> On Oct 26, 2018, at 3:34 PM, Zachary Turner <ztur...@google.com> wrote:
>
> So, the second command works, but the first one doesn't. It doesn't give any
> error, but on the other hand, it doesn't change the results of printing the
> variable. When I run type category list though, I get this:
>
> (lldb) type category list
> Category: default (enabled)
> Category: VectorTypes (enabled, applicable for language(s): objective-c++)
> Category: system (enabled, applicable for language(s): objective-c++)
>
> So it looks like the behavior I'm seeing is already with the default
> category. Does this sound right? Which code path is supposed to get
> executed to format it as a C++ class?
>
> On Fri, Oct 26, 2018 at 10:25 AM Jim Ingham <jing...@apple.com> wrote:
> Remove the "not"...
>
> Jim
>
> > On Oct 26, 2018, at 10:24 AM, Jim Ingham <jing...@apple.com> wrote:
> >
> > But at the minimum, not loading formatters for a language that we can
> > determine isn't used in this program seems like something we should try to
> > avoid.
>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
