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

Fri Oct 16 15:01:39 PDT 2015

Alright, let's try to fix the bug.

Let's work backward from the leaves: clang's ASTImporter.cpp:2979 and
AstImporter.cpp:3044. In the backtrace, what seems to be most relevant
is a call inside layoutRecordType, namely ClangASTSource.cpp:1709. The
codebase clearly shows efforts to emit "Please retry with
-fno-limit-debug-info", so I can infer that we intend to catch every
non-IsStructurallyEquivalent before it goes to clang, and emit a good
error message if best-effort fails. ClangASTContext.cpp is littered
with `omit_empty_base_classes`, so some machinery to handle forward
declarations properly is already in place.

Back to where we were debugging. GetCompleteDecl seems relevant, and
we aren't using its return value, so we have no way of telling if it's
a complete definition, right? Why am I guessing instead of
interactively debugging? Because the debugger is useless at this
stage, thanks to the same bug :)

I think the bug is just a matter of missing a corner case, but I could
be wrong. Let me know your thoughts.

Ram

On Wed, Oct 14, 2015 at 11:06 AM, Ramkumar Ramachandra
<artagnon at gmail.com> wrote:
> Thanks for an excellent explanation.
>
> Unfortunately, -fno-limit-debug-info did not fix the problem; and that
> I don't see the problem with a gcc/gdb setup.
>
> So what I'm doing is forward-declaring LLVM IR entities (like `Value',
> `Type', `Function'), so that multiple downstream modules don't include
> those LLVM headers potentially double-including global statics. I'm
> trying to look inside an llvm::Function * in the debugger now, and it
> fails.
>
> I'm going to try building LLVM itself with -fno-limit-debug-info now.
> Let me know if there are other things I can try.
>
> Thanks.
>
> Ram
>
> On Tue, Oct 13, 2015 at 6:26 PM, Greg Clayton <gclayton at apple.com> wrote:
>> In LLDB we create clang::ASTContext objects for the modules (executable and shared libraries), one for the target to contain the expression results, and one for each expression.
>>
>> When we evaluate an expression we might do something like:
>>
>> (lldb) expr a + b
>>
>> where "a" is from liba.so and "b" is from libb.so. We must copy types from the clang::ASTContext for each module, so we will copy the type of "a" into the expression clang::ASTContext and we will also copy type "b" from the clang::ASTContext from libb.so into the expression clang::ASTContext. Many times we the same types, but one has more information in it. Like lets say both "a" and "b" are type "foo<int>". We can often end up with different definitions of "foo<int>" in liba.so and libb.so and when we try to copy the types, we first copy "foo<int>" from liba.so into the expression AST, and then we do the same with "b" from libb.so, but it notices that the types are the same level, so it tries to verify the types are the same. This often fails due to debug info being more complete in one of the shared libraries. One example is the compiler might omit the complete definition for a base class in libb.so where it has a complete definition for the base class in liba.so. When parsing types we must always give clang something it is happy with, so if we run into debug info that has a complete definition for "foo<int>", but it inherits from class "C". So the definition for "C" in liba.so is:
>>
>> class C
>> {
>> public:
>>     C();
>>     ~C();
>>     int callme();
>> };
>>
>> and "C" in "libb.so" is just a forward declaration:
>>
>> class C;
>>
>> But then int libb.so we must create a type for foo<int> but we can't since C isn't complete, but we do anyway by just saying C looks like:
>>
>> class C
>> {
>> };
>>
>> So now we have two types that differ, and importing both foo<int> types into the expression clang::ASTContext will fail. This happens a lot for C++ template classes because of the haphazard way that compilers generate debug info for templates. It could be a bug in the type importer where the two types are actually the same, but the type importer thinks they are different, but often it is because the types actually do differ.
>>
>> One way to get around the compiler emitting forward declarations to base classes is to specify: -fno-limit-debug-info
>>
>> This will disable the debug info minimizing feature and make the compiler emit more complete debug info and it might fix your problem.
>>
>> Greg Clayton
>>
>>> On Oct 13, 2015, at 10:44 AM, Ramkumar Ramachandra via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>>>
>>> Hi,
>>>
>>> At one point in the debugging session, I get this when I try to print
>>> a particular value:
>>>
>>> error: field '__r_' declared with incompatible types in different
>>> translation units
>>> ('std::__1::__compressed_pair<std::__1::basic_string<char,
>>> std::__1::char_traits<char>, std::__1::allocator<char> >::__rep,
>>> std::__1::allocator<char> >' vs.
>>> 'std::__1::__compressed_pair<std::__1::basic_string<char,
>>> std::__1::char_traits<char>, std::__1::allocator<char> >::__rep,
>>> std::__1::allocator<char> >')
>>> error: field '__r_' declared with incompatible types in different
>>> translation units
>>> ('std::__1::__compressed_pair<std::__1::basic_string<char,
>>> std::__1::char_traits<char>, std::__1::allocator<char> >::__rep,
>>> std::__1::allocator<char> >' vs.
>>> 'std::__1::__compressed_pair<std::__1::basic_string<char,
>>> std::__1::char_traits<char>, std::__1::allocator<char> >::__rep,
>>> std::__1::allocator<char> >')
>>> error: field '__r_' declared with incompatible types in different
>>> translation units
>>> ('std::__1::__compressed_pair<std::__1::basic_string<char,
>>> std::__1::char_traits<char>, std::__1::allocator<char> >::__rep,
>>> std::__1::allocator<char> >' vs.
>>> 'std::__1::__compressed_pair<std::__1::basic_string<char,
>>> std::__1::char_traits<char>, std::__1::allocator<char> >::__rep,
>>> std::__1::allocator<char> >')
>>> error: field '__r_' declared with incompatible types in different
>>> translation units
>>> ('std::__1::__compressed_pair<std::__1::basic_string<char,
>>> std::__1::char_traits<char>, std::__1::allocator<char> >::__rep,
>>> std::__1::allocator<char> >' vs.
>>> 'std::__1::__compressed_pair<std::__1::basic_string<char,
>>> std::__1::char_traits<char>, std::__1::allocator<char> >::__rep,
>>> std::__1::allocator<char> >')
>>> note: declared here with type
>>> 'std::__1::__compressed_pair<std::__1::basic_string<char,
>>> std::__1::char_traits<char>, std::__1::allocator<char> >::__rep,
>>> std::__1::allocator<char> >'
>>> note: declared here with type
>>> 'std::__1::__compressed_pair<std::__1::basic_string<char,
>>> std::__1::char_traits<char>, std::__1::allocator<char> >::__rep,
>>> std::__1::allocator<char> >'
>>> note: declared here with type
>>> 'std::__1::__compressed_pair<std::__1::basic_string<char,
>>> std::__1::char_traits<char>, std::__1::allocator<char> >::__rep,
>>> std::__1::allocator<char> >'
>>> note: declared here with type
>>> 'std::__1::__compressed_pair<std::__1::basic_string<char,
>>> std::__1::char_traits<char>, std::__1::allocator<char> >::__rep,
>>> std::__1::allocator<char> >'
>>>
>>> (which makes no sense at all; lhs and rhs are identical)
>>>
>>> After that point, whatever I try to print returns this error.
>>>
>>> What is going on?
>>>
>>> Thanks.
>>>
>>> Ram
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>