Also, I assume the extra changes to make the PointerIntPair formatter work will be in a follow-up patch?

In D156774#4644503, @Endill wrote:

Ping @Michael137

We worked around this in xcode

In D157907#4607147, @aeubanks wrote:

In D157907#4607125, @Michael137 wrote:

In D157907#4607118, @aeubanks wrote:

I've reverted the patch, yeah seeing the IR would be useful

I won't be on my PC for the next 12 hours or so. I shared the IR with @jasonmolenda earlier today, hopefully he can forward it to you

If you have access to a x86_64 (or Rosetta) Darwin machine you should be able to repro it by compiling lldb/test/API/commands/expression/import-std-module/deque-basic/main.cpp with your changes and attaching lldb as follows:

./bin/lldb a.out -o "sett set target.import-std-module true" -o "br se -p return -X main" -o run -o "expr std::sort(a.begin(), a.end())"

I'm not in a rush to get this relanded so posting the IR later is fine

I attached the module it's blowing up on

In D157907#4607118, @aeubanks wrote:

I've reverted the patch, yeah seeing the IR would be useful

In D157907#4605677, @jasonmolenda wrote:

Hi, this is causing a regression on the greendragon x86_64 lldb bot, it took a little while to repo and narrow down today. https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/ is failing on TestDequeFromStdModule.py, I can repo it on an intel mac. We're crashing under

LLVM ERROR: unable to evaluate offset to undefined symbol 'L21$pb'

4   liblldb.18.0.0git.dylib       	       0x1357b08a4 llvm::report_fatal_error(llvm::Twine const&, bool) + 388 (ErrorHandling.cpp:123)
5   liblldb.18.0.0git.dylib       	       0x13f73da2b getLabelOffset(llvm::MCAsmLayout const&, llvm::MCSymbol const&, bool, unsigned long long&) + 187 (MCFragment.cpp:107)
6   liblldb.18.0.0git.dylib       	       0x13f73aa48 getSymbolOffsetImpl(llvm::MCAsmLayout const&, llvm::MCSymbol const&, bool, unsigned long long&) + 72 (MCFragment.cpp:118)
7   liblldb.18.0.0git.dylib       	       0x13f73abde getSymbolOffsetImpl(llvm::MCAsmLayout const&, llvm::MCSymbol const&, bool, unsigned long long&) + 478 (MCFragment.cpp:143)
8   liblldb.18.0.0git.dylib       	       0x13f73ac56 llvm::MCAsmLayout::getSymbolOffset(llvm::MCSymbol const&) const + 38 (MCFragment.cpp:158)
9   liblldb.18.0.0git.dylib       	       0x13f6df97f llvm::MCAssembler::evaluateFixup(llvm::MCAsmLayout const&, llvm::MCFixup const&, llvm::MCFragment const*, llvm::MCValue&, unsigned long long&, bool&) const + 1151 (MCAssembler.cpp:262)
10  liblldb.18.0.0git.dylib       	       0x13f6e2aec llvm::MCAssembler::handleFixup(llvm::MCAsmLayout const&, llvm::MCFragment&, llvm::MCFixup const&) + 92 (MCAssembler.cpp:804)
11  liblldb.18.0.0git.dylib       	       0x13f6e362b llvm::MCAssembler::layout(llvm::MCAsmLayout&) + 2651 (MCAssembler.cpp:933)
12  liblldb.18.0.0git.dylib       	       0x13f6e40cd llvm::MCAssembler::Finish() + 77 (MCAssembler.cpp:944)
13  liblldb.18.0.0git.dylib       	       0x13f75b10b llvm::MCObjectStreamer::finishImpl() + 203 (MCObjectStreamer.cpp:932)
14  liblldb.18.0.0git.dylib       	       0x13f744709 (anonymous namespace)::MCMachOStreamer::finishImpl() + 761 (MCMachOStreamer.cpp:533)
15  liblldb.18.0.0git.dylib       	       0x13f785b10 llvm::MCStreamer::finish(llvm::SMLoc) + 224 (MCStreamer.cpp:1021)
16  liblldb.18.0.0git.dylib       	       0x1381ac986 llvm::AsmPrinter::doFinalization(llvm::Module&) + 6502 (AsmPrinter.cpp:2398)
17  liblldb.18.0.0git.dylib       	       0x13f1708ae llvm::FPPassManager::doFinalization(llvm::Module&) + 78 (LegacyPassManager.cpp:1499)
18  liblldb.18.0.0git.dylib       	       0x13f1699be (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) + 1358 (LegacyPassManager.cpp:1586)
19  liblldb.18.0.0git.dylib       	       0x13f1692ba llvm::legacy::PassManagerImpl::run(llvm::Module&) + 266 (LegacyPassManager.cpp:535)
20  liblldb.18.0.0git.dylib       	       0x13f170af1 llvm::legacy::PassManager::run(llvm::Module&) + 33 (LegacyPassManager.cpp:1677)
21  liblldb.18.0.0git.dylib       	       0x138d51d7d llvm::MCJIT::emitObject(llvm::Module*) + 477 (MCJIT.cpp:171)

@Michael137 might be better able to understand the nature of the regression, I'm not very familiar with this part of llvm, I'm trying to get repo steps for him on an aarch64 mac to build & run it under translation. I think we'll need to revert this until we can figure out the failure.

FYI, looks like debug-info tests started failing on the public x86_64 bot after this patch: https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/59089/console

In D156774#4601767, @Endill wrote:

In D156774#4601736, @Michael137 wrote:

What were your lldb commands when you tested this?

script import lldb; frame = lldb.thread.GetFrameAtIndex(0); print(frame.variables[0].type.GetNumberOfMemberEnums())

LLDB currently completes types lazily when it thinks it can. Does your new API still fail if you run expr p prior? (the idea is that that would trigger completion of the type and parse dwarf). If we dont ever call GetFullCompilerType on your type LLDB will never try to pull in the definition

No amount of tinkering with expr makes script print(frame.variables[0].type.GetNumberOfMemberEnums()) output a non-zero value.
I tested this with the changes I uploaded here half an hour ago.

In D156774#4601705, @Endill wrote:

I tested this patch together with the following new code:

uint32_t TypeSystemClang::GetNumMemberEnums(lldb::opaque_compiler_type_t type) {
  using EnumIt = clang::DeclContext::specific_decl_iterator<clang::EnumDecl>;
  if (!type)
    return 0;
  clang::QualType qual_type = RemoveWrappingTypes(GetCanonicalQualType(type));
  clang::DeclContext *ctx = qual_type->getAsRecordDecl()->getDeclContext();
  return std::distance(EnumIt(ctx->decls_begin()), EnumIt(ctx->decls_end()));
}

CompilerType
TypeSystemClang::GetMemberEnumAtIndex(lldb::opaque_compiler_type_t type,
                                      size_t index) {
  using EnumIt = clang::DeclContext::specific_decl_iterator<clang::EnumDecl>;
  if (!type)
    return CompilerType();

  clang::QualType qual_type = RemoveWrappingTypes(GetCanonicalQualType(type));
  clang::DeclContext *ctx = qual_type->getAsRecordDecl()->getDeclContext();
  size_t enum_index = 0;
  for (EnumIt enums_it(ctx->decls_begin()), enums_end(ctx->decls_end());
       enums_it != enums_end;
       ++enums_it, ++enum_index) {
      if (enum_index == index) {
        return CompilerType(weak_from_this(), *enums_it);
      }
  }
}

I created all the wrappers to make it available in Python. The result was unsatisfactory: this code doesn't even trigger DWARFASTParserClang::ParseChildMembers that this patch touches, and return 0 instead of 1. This doesn't change even if I trigger ParseChildMembers via other means before asking for a number of member enums in a type.

Code I tested this on:

using intptr_t = long;
using uintptr_t = unsigned long;

struct PointerIntPairInfo {
  enum MaskAndShiftConstants : uintptr_t {
    PointerBitMask =
        ~(uintptr_t)(((intptr_t)1 << 3) - 1),
  };

  int a{};
};

static uintptr_t dummy() {
  return PointerIntPairInfo::PointerBitMask;
}

int main()
{
    PointerIntPairInfo p;
    __builtin_debugtrap();
    return p.a + foo();
}

If you have any suggestions what I missed or did wrong, please let me know.

I'll continue with this patch nevertheless, but it's clear now that there's still a way to go until I can access that enum without going through slow expression evaluator.

• Reword commit message

• Reword commit message

• Remove drive-by change

In D156774#4572967, @Endill wrote:

In D156774#4572947, @Michael137 wrote:

Are you still planning on moving this forward? Otherwise I could commandeer the revision to get this in. I do think it's a useful bug to address

I do. Locally I've been preparing additional changes on top of this patch that expose enums in SBType, so that I can do end-to-end test to ensure this sufficiently addresses my use case.
On top of that, I'm planning to redo this patch after the example of DW_TAG_subprogram per your suggestion.

Unfortunately, I didn't have time last week for this, and now I'm knee deep into triaging old Clang bugs. I'm not finished with that until number of open issues is brought under 20k :)

Are you still planning on moving this forward? Otherwise I could commandeer the revision to get this in. I do think it's a useful bug to address

Hi, this is failing on swift-ci (runs on x86 bots) with the following error:

Could you please elaborate in the commit message what exactly the issue currently is and how the patch addresses it?

Could you update the commit message with a description of the failure and summary of the fix? And change the title to something like [lldb][DWARFASTParserClang] Resolve nested types when parsing structures

LGTM

• Amend commit message

LGTM

Thanks for addressing this.

LGTM

Generally LGTM, just some clarifications questions

• EXPECT -> ASSERT

• Fix test

• Parameterize tests
• Return bool to indicate SDK mismatch

Generally LGTM, just left some minor comments

• Update unit-tests
• Expand function docs

• Remove more headers

• Remove redundant header

• Move into PlatformDarwin
• Return XcodeSDK from GetSDKPathFromDebugInfo so it's easier to re-use from Swift plugin
• Introduce ResolveSDKPathFromDebugInfo to be used from PlatformDarwin
• Adjust tests

• Remove redundant headers

All my comments seem to have been submitted on a stale revision. So they shifted up a couple of lines. But looks like Phabricator doesn't allow me to delete/move them

In D154709#4487776, @balazske wrote:

The goal is to have a message always in ASTImportError? Then probably the constructor without message can be removed, at least to check if really the message is added at all places. I found that it is missing in VisitObjCImplementationDecl.

LGTM, thanks!

• Fix commit message

Didn't add tests for this since checking the contents of the error message didn't seem worth testing.
But don't mind adding tests if reviewers feel more comfortable

• Remove redundant header additions

• clang-format

• remove redundant includes

This is now failing with:

clang: warning: argument unused during compilation: '-fmodules-cache-path=/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lldb-test-build.noindex/module-cache-clang/lldb-shell' [-Wunused-command-line-argument]
Undefined symbols for architecture x86_64:
  "abort", referenced from:
      asm_main in eh-frame-dwarf-unwind-abort-edbc93.o
     (maybe you meant: g_hard_abort)
ld: symbol(s) not found for architecture x86_64

• fix test comment

Looks like this is failing on the Darwin x86_64 buildbots: https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/56510/execution/node/74/log/

@MaskRay Looks like this broke the x86_64 LLDB buildbots: https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/56511/execution/node/43/log/

Looks like this broke the lldb matrix bots for DWARFv2: https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-matrix/6580/execution/node/54/log/

********************
Failed Tests (2):
  lldb-api :: lang/c/tls_globals/TestTlsGlobals.py
  lldb-api :: lang/cpp/thread_local/TestThreadLocal.py

In D144999#4417731, @oontvoo wrote:

In D144999#4415419, @oontvoo wrote:

In D144999#4415137, @jasonmolenda wrote:

Michael and I looked into this. This simple c++ file is resulting in eh_frame unwind info on aarch64 darwin instead of compact unwind info.

P.S: still no luck reproducing this with TOT clang. Would you mind verifying my test case below (this was on M1 mac):

### clang is built with commit up to 5b1c62c0f2e9a739707429f650cb897c067f86c2
vyng-macbookpro3 /Users/vyng/repo/llvm-project/build_all$ ./bin/clang++  ../cross-project-tests/debuginfo-tests/dexter-tests/optnone-struct-and-methods.cpp -g -O0 -c -o test_tot.o

vyng-macbookpro3 /Users/vyng/repo/llvm-project/build_all$ objdump --macho --unwind-info --dwarf=frames  test_tot.o
Contents of __compact_unwind section:
  Entry at offset 0x0:
    start:                0x0 ltmp0
    length:               0x70
    compact encoding:     0x44000000
    personality function: 0x0 ___gxx_personality_v0
    LSDA:                 0x238 ltmp1
  Entry at offset 0x20:
    start:                0x70 __ZN12_GLOBAL__N_11AC1Ev
    length:               0x2c
    compact encoding:     0x04000000
  Entry at offset 0x40:
    start:                0x9c __ZN12_GLOBAL__N_11A7getDataEv
    length:               0x78
    compact encoding:     0x04000000
  Entry at offset 0x60:
    start:                0x114 __ZN12_GLOBAL__N_11AD1Ev
    length:               0x2c
    compact encoding:     0x04000000
  Entry at offset 0x80:
    start:                0x140 __ZN12_GLOBAL__N_11AC2Ev
    length:               0x2c
    compact encoding:     0x02001000
  Entry at offset 0xa0:
    start:                0x16c __ZN12_GLOBAL__N_11A12setOtherDataEv
    length:               0x74
    compact encoding:     0x04000000
  Entry at offset 0xc0:
    start:                0x1e0 __ZN12_GLOBAL__N_11A12getOtherDataEv
    length:               0x18
    compact encoding:     0x02001000
  Entry at offset 0xe0:
    start:                0x1f8 __ZN12_GLOBAL__N_11AD2Ev
    length:               0x40
    compact encoding:     0x04000000

.debug_frame contents:


.eh_frame contents:
<<<< nothing in eh_frame section, which is expected and matches what produced by base clang