This is an archive of the discontinued LLVM Phabricator instance.

[lldb][test] TestConstStaticIntegralMember.py: fix for clang-{9,11,13}
ClosedPublic

Authored by Michael137 on Nov 10 2022, 10:56 AM.

Details

Summary

Summary

The public lldb matrix bot is failing for tests compiled with clang-9, clang-11, clang-13.

This patch addresses these failures by evaluating the enum case that
doesn't cause malformed DWARF in older version of clang.

There was no particular reason we had to use true enum case
to reproduce the bug in #58383, so simply switch to use false
to get all bots passing again.

Details

In older versions of clang, the following snippet:

enum EnumBool : bool {
  enum_bool_case1 = false,
  enum_bool_case2 = true,
};

struct A {
  const static EnumBool enum_bool_val = enum_bool_case2;
};

…results in following DWARF:

0x00000052:   DW_TAG_structure_type
                DW_AT_calling_convention        (DW_CC_pass_by_value)
                DW_AT_name      ("A")
                DW_AT_byte_size (0x01)
                DW_AT_decl_file ("/Users/michaelbuch/Git/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/repro.cpp")
                DW_AT_decl_line (6)

0x0000005b:     DW_TAG_member
                  DW_AT_name    ("enum_bool_val")
                  DW_AT_type    (0x0000000000000068 "const EnumBool")
                  DW_AT_decl_file       ("/Users/michaelbuch/Git/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/repro.cpp")
                  DW_AT_decl_line       (7)
                  DW_AT_external        (true)
                  DW_AT_declaration     (true)
                  DW_AT_const_value     (-1)

Note the DW_AT_const_value == -1

When evaluating A::enum_bool_val in the lldb we get:

(lldb) p A::enum_bool_val
error: expression failed to parse:
error: Couldn't lookup symbols:
  __ZN1A13enum_bool_valE

Enabling the DWARF logs we see:

(arm64) clang-13.out: DWARFASTParserClang::ParseTypeFromDWARF (die = 0x00000068, decl_ctx = 0x136ac1e30 (die 0x0000000b)) DW_TAG_const_type name = '(null)')
Failed to add const value to variable A::enum_bool_val: Can't store unsigned value 18446744073709551615 in integer with 1 bits.

This occurs because a boolean enum is considered an unsigned integer
type, but we try to initialize it with a -1.

Testing

  • Confirmed locally that top-of-tree lldb correctly evaluates the previously failing expression when the test program is compiled with clang-13

Diff Detail

Event Timeline

Michael137 created this revision.Nov 10 2022, 10:56 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 10 2022, 10:56 AM
Michael137 requested review of this revision.Nov 10 2022, 10:56 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 10 2022, 10:56 AM
aeubanks accepted this revision.Nov 10 2022, 1:47 PM

add a FIXME?

This revision is now accepted and ready to land.Nov 10 2022, 1:47 PM
Michael137 added a comment.EditedNov 10 2022, 1:58 PM

add a FIXME?

May be misunderstanding your suggestion, but the malformed DWARF got fixed somewhere between clang-14/clang-15. This is only an issue with older clang versions. I'm merely getting the old buildbots to pass

add a FIXME?

May be misunderstanding your suggestion, but the malformed DWARF got fixed somewhere between clang-14/clang-15. This is only an issue with older clang versions. I'm merely getting the old buildbots to pass

I guess my question is should lldb support the malformed dwarf generated by older clangs?

add a FIXME?

May be misunderstanding your suggestion, but the malformed DWARF got fixed somewhere between clang-14/clang-15. This is only an issue with older clang versions. I'm merely getting the old buildbots to pass

I guess my question is should lldb support the malformed dwarf generated by older clangs?

Ah I see, fair question. Presumably one of the reasons we don't bubble up the error from the DWARFASTParserClang to the expression evaluator is specifically because the DWARF can be malformed and evaluation may still succeed. In this case though I'm not sure we can do much because the generated DWARF breaks assumptions that LLDB (via Clang) makes about signedness. I'll double check the exact machinery though and report back