[lldb-dev] lldb showing wrong type structure for virtual pointer type

[jonas echterhoff via lldb-dev]

Hi,

I'm having a problem where lldb will resolve the wrong type for virtual pointers, showing incorrect data for variables. This makes debugging our project very hard.

In our project, we commonly have the following structure:

class Transform : SomeParentClass
{
   virtual foo();
   void bar();
   /*...*/
}

namespace Scripting {
class Transform : SomeScriptingParentClass
{
   /*...*/
}
}

ie, we have native internal classes (like "Transform" in this case), and wrapper classes with identical names (but in a different namespace). (These are used to link the native class to a user facing API of the same name).

Now, when I put a breakpoint into "Transform::bar" and try to inspect the "this" variable, lldb shows "this" as a pointer to "Scripting::Transform" instead of as a pointer to "::Transform", thus showing the wrong data and making it impossible to inspect it's member variables. Since this is a common structure in our code, it makes debugging very hard.

Now, it seems that this is caused by Transform being a virtual class. So lldb will try to derive it's type at runtime by looking at the symbol name of the vtable (which is "__ZTV9Transform"). Then it will incorrectly map that to "Scripting::Transform" instead of "::Transform", which seems to be a bug in lldb.

I can work around the problem by patching the mach-o binary to remove the name of the vtable ("__ZTV9Transform") from the symbol table. Then lldb will be unable to look up the type dynamically at runtime, and use the dwarf info of the "bar" function, which specifies "this" to be a pointer to "::Transform". Obviously, this is a rather inconvenient workaround.

I guess I could rename the scripting representations of all our classes to use a different naming scheme (like "Scripting::_Transform"), but I'd only like to do that as a last resort.

I'm using lldb-900.0.64.
Unfortunately, I have not yet succeeded in coming up with a small, independent repro case which shows this problem.

So I'm wondering:
-Is this a known issue?
-Is there a fix?
-Any ideas for a better workaround?

Thanks for any help!

jonas