[lldb-dev] [BUG?] Confusion between translation units?

Greg Clayton via lldb-dev lldb-dev at lists.llvm.org
Tue Nov 3 14:19:40 PST 2015


> On Nov 3, 2015, at 1:12 PM, Ramkumar Ramachandra <artagnon at gmail.com> wrote:
> 
> Greg Clayton wrote:
>> Be sure to use "frame variable" more as it will never run into these type importation problems when you need to view a variable or members of a variable.
>> 
>> It would be interesting to see the output of "frame variable" from frame 0 and frame 4 and see if they differ at all.
> 
> `fr va` seems to fix the immediate problem, thanks! I'll let you know
> if I run into issues with it.
> 
> We really should fix the expression parser, no?

Yes, but we need to identify the problem.

> Why is it behaving strangely?

There are many clang::ASTContext objects in LLDB. 1 per module, 1 per target and 1 for each expression. We import types from one AST to another. When running expressions we import one type for "foo<int>" from liba.so into the expression AST, then we might try to import another from libb.so into the expression AST. If the "foo<int>" type is already in the expression AST, then we need to verify the two types are the same. When this fails, then the expression fails.

So we need to determine which two versions of "foo<int>" are different and where they differ so we can understand how to fix this.

Follow my previous suggestions: enable lldb expr logging and also compare the output of the two "frame variable F" for frame 0 and frame 4 in your previous example. Since "frame variable" always uses the type _only_ from liba.so or libb.so, we might be able to see a difference in the output of "frame variable F" for the two frames. If we don't see any difference, we need to dump the type from "image lookup --all -t "foo<int>" and see if we see any differences there. If we don't see differences we need to then step through the code that is attempting to import "foo<int>" the second time and see where it thinks the types differ.

Greg Clayton



More information about the lldb-dev mailing list