[lldb] Fix complex integer type parsing for GCC

[teemperor]

Summary

It seems GCC gives complex integer types that don't have int as the base type
the name __unknown__ instead of complex X or something similar. This patch just
adapts our DWARF parsing logic to also treat DW_ATE_lo_user as a complex
integer type if the name is __unknown__.

Fixes the TestComplexInt test with GCC as the test compiler.

[werat]

Is this specific to GCC? To be on the safe side, would it make sense to check like type_name == "__unknown__" && compiler == GCC?

[teemperor]

In D104444#2824347, @werat wrote:

Is this specific to GCC? To be on the safe side, would it make sense to check like type_name == "__unknown__" && compiler == GCC?

Clang is emitting the correct names while GCC isn't (kinda ironic as GCC came up with that whole complex int extension from what I remember). I'll add a producer check for GCC here, that seems like a good idea, thanks!

[jankratochvil]

FYI GDB does not support these complex types.
GCC discusses it as PR debug/93988.

lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp

976

979

clang creates it with such plain name. During my GIT archeology it was always this way. Although I do not know if clang cannot create derived type names from it. Ignore this comment if you think so. Also this is a change orthogonal to this patch.

[teemperor]

In D104444#2824780, @jankratochvil wrote:

FYI GDB does not support these complex types.
GCC discusses it as PR debug/93988.

Good to know. FWIW, I don't feel strongly about supporting these types (I doubt there are any real users), but supporting them isn't a lot of work so why not.

lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp

976

Thanks!

979

Yeah that change to == was an accident, let's revert that. Thanks!

[jankratochvil]

lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp

979

Not sure if it is not a misunderstanding. There always was type_name.contains("complex") and you kept it that way. But you added || type_name == "__unknown__". Now the question is why it should be different. So

• either type_name.contains("complex") || type_name.contains("__unknown__") if clang can derive some new type name from existing type name such as "unsigned complex" (but I do not think it can)
• or type_name == "complex" || type_name == "__unknown__" which should work IMHO but it is changing also the clang-producer-specific part which does not necessarily belong to this patch (but it can be another patch).

lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp

if (QualTypeMatchesBitSize(bit_size, ast, ast.UnsignedCharTy))
       return GetType(ast.UnsignedCharTy);
     if (QualTypeMatchesBitSize(bit_size, ast, ast.UnsignedShortTy))
       return GetType(ast.UnsignedShortTy);
     if (QualTypeMatchesBitSize(bit_size, ast, ast.UnsignedIntTy))
       return GetType(ast.UnsignedIntTy);
     break;
 
   case DW_ATE_lo_user:
-    // This has been seen to mean DW_AT_complex_integer
-    if (type_name.contains("complex")) {
+    // Clang and GCC use this for DW_AT_complex_integer. GCC is emitting for
+    // base types other than int the name '__unknown__' with the correct bit
+    // size, so we also treat that as a complex integer type.
+    if (type_name.contains("complex") || type_name == "__unknown__") {
       CompilerType complex_int_clang_type =
           GetBuiltinTypeForDWARFEncodingAndBitSize("int", DW_ATE_signed,
                                                    bit_size / 2);
       return GetType(
           ast.getComplexType(ClangUtil::GetQualType(complex_int_clang_type)));
     }
     break;