Page MenuHomePhabricator

[lldb] Fix complex integer type parsing for GCC
Changes PlannedPublic

Authored by teemperor on Jun 17 2021, 2:33 AM.

Details

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.

Diff Detail

Event Timeline

teemperor created this revision.Jun 17 2021, 2:33 AM
teemperor requested review of this revision.Jun 17 2021, 2:33 AM
teemperor added a reviewer: werat.
werat accepted this revision.Jun 17 2021, 5:22 AM

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

This revision is now accepted and ready to land.Jun 17 2021, 5:22 AM
teemperor planned changes to this revision.Jun 17 2021, 6:35 AM

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 accepted this revision.Jun 17 2021, 8:28 AM

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.

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 added inline comments.Jun 17 2021, 11:03 AM
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).