[lldb-dev] [BUG?] Confusion between translation units?
Greg Clayton via lldb-dev
lldb-dev at lists.llvm.org
Fri Oct 16 17:20:16 PDT 2015
> On Oct 16, 2015, at 3:01 PM, Ramkumar Ramachandra <artagnon at gmail.com> wrote:
>
> 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.
No this is just so you don't see a mess in the variable view. If you have empty base classes A, B, and C, and you have class D:
class D : public A, public B, public C
{
int m_a;
};
You don't want to have your variable view look like:
d-.
|- A
|- B
|- C
\- m_a
You would rather see:
d-.
\- m_a
So this is what imit_empty_base_classes aims to fix: showing tons of class structure that doesn't contribute to efficient variable viewing in the debugger. C++ classes in the "std" namespace have a ton of useless stuff that shows up if you don't do this:
my_str-.
|- <std::allocator <blah blah>
|- <std::allocator2 <blah blah>
|- <std::allocator3 <blah blah>
\- m_data
>
> 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 :)
Yes I have seen a bunch of problems like this on linux due to types being incomplete in the debug info (my guess). But I would like to verify that the manual DWARF indexing isn't to blame for this. We have great accelerator tables that the clang makes for us that actually have all of the info we need to find types and functions quickly, whereas all other platforms must run SymbolFileDWARF::Index() to manually index the DWARF.
>
> I think the bug is just a matter of missing a corner case, but I could
> be wrong. Let me know your thoughts.
I should be able to tell if you can send me an ELF file and say where you were and wait wasn't showing up correctly (which variables) in an exact code context (which file + line or exact line in a function). Then I can verify that SymbolFileDWARF::Index() is correctly indexing things so that we can find types and functions when we need them.
Greg
>
> 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
>>>
More information about the lldb-dev
mailing list