[PATCH] D113741: [RFC][DwarfDebug][AsmPrinter] Support emitting function-local declaration for a lexical block

Wed Dec 22 14:17:57 PST 2021

dblaikie added a comment.

In D113741#3207109 <https://reviews.llvm.org/D113741#3207109>, @krisb wrote:

> @dblaikie, thank you for the reproducers!
>
> I've tried to compile&examine them, but haven't found any issues. Likely, I did something wrong.
> Could you, please, give more details on how to reproduce the issue(s)? I mean, exact compilation command line and/or crash details / wrong dwarf output? Thank you!

Oh, right, sorry:

For the first one, you should observe a crash (in a +Asserts build) when running this command:

  $ clang++-tot ab-crash.ll -gsplit-dwarf -c -O1

The backtrace looks something like this:

  $ clang++-tot ab-crash.ll -gsplit-dwarf -c -O1 -S 
  clang++-tot: /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp:660: llvm::DIE *llvm::DwarfCompileUnit::constructInlinedScopeDIE(llvm::LexicalScope *): Assertion `OriginDIE && "Unable to find original DIE for an inlined subprogram."' failed.
  PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
  Stack dump:
  0.      Program arguments: clang++-tot ab-crash.ll -gsplit-dwarf -c -O1 -S
  1.      Code generation
  2.      Running pass 'Function Pass Manager' on module 'ab-crash.ll'.
  3.      Running pass 'X86 Assembly Printer' on function '@main'
   #0 0x0000000009e604ea llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/Support/Unix/Signals.inc:565:11
   #1 0x0000000009e6069b PrintStackTraceSignalHandler(void*) /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/Support/Unix/Signals.inc:632:1
   #2 0x0000000009e5ed63 llvm::sys::RunSignalHandlers() /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/Support/Signals.cpp:97:5
   #3 0x0000000009e5fdfe llvm::sys::CleanupOnSignal(unsigned long) /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/Support/Unix/Signals.inc:362:1
   #4 0x0000000009d6fa4e (anonymous namespace)::CrashRecoveryContextImpl::HandleCrash(int, unsigned long) /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/Support/CrashRecoveryContext.cpp:0:7
   #5 0x0000000009d6fe03 CrashRecoverySignalHandler(int) /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/Support/CrashRecoveryContext.cpp:390:1
   #6 0x00007f60568c08e0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x138e0)
   #7 0x00007f6056389e71 raise ./signal/../sysdeps/unix/sysv/linux/raise.c:50:1
   #8 0x00007f6056373536 abort ./stdlib/abort.c:81:7
   #9 0x00007f605637341f get_sysdep_segment_value ./intl/loadmsgcat.c:509:8
  #10 0x00007f605637341f _nl_load_domain ./intl/loadmsgcat.c:970:34
  #11 0x00007f60563827f2 (/lib/x86_64-linux-gnu/libc.so.6+0x357f2)
  #12 0x000000000b57ce6e llvm::DwarfCompileUnit::constructInlinedScopeDIE(llvm::LexicalScope*) /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp:0:3
  #13 0x000000000b57cb6c llvm::DwarfCompileUnit::constructScopeDIE(llvm::LexicalScope*, llvm::DIE&) /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp:538:10
  #14 0x000000000b57d3ae llvm::DwarfCompileUnit::createAndAddScopeChildren(llvm::LexicalScope*, llvm::DIE&) /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp:1072:7
  #15 0x000000000b57efa1 llvm::DwarfCompileUnit::constructSubprogramScopeDIE(llvm::DISubprogram const*, llvm::LexicalScope*) /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp:1023:14
  #16 0x000000000b52bc0d llvm::DwarfDebug::endFunctionImpl(llvm::MachineFunction const*) /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:2301:50
  #17 0x000000000b505ab2 llvm::DebugHandlerBase::endFunction(llvm::MachineFunction const*) /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/CodeGen/AsmPrinter/DebugHandlerBase.cpp:0:5
  #18 0x000000000b4e1f4c llvm::AsmPrinter::emitFunctionBody() /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:1505:3
  #19 0x0000000007ed7113 llvm::X86AsmPrinter::runOnMachineFunction(llvm::MachineFunction&) /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/Target/X86/X86AsmPrinter.cpp:82:3
  #20 0x0000000008a96477 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/CodeGen/MachineFunctionPass.cpp:72:8
  #21 0x0000000009165d5e llvm::FPPassManager::runOnFunction(llvm::Function&) /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/IR/LegacyPassManager.cpp:1439:23
  #22 0x000000000916abb2 llvm::FPPassManager::runOnModule(llvm::Module&) /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/IR/LegacyPassManager.cpp:1485:16
  #23 0x0000000009166649 (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/IR/LegacyPassManager.cpp:1554:23
  #24 0x00000000091661bd llvm::legacy::PassManagerImpl::run(llvm::Module&) /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/IR/LegacyPassManager.cpp:542:16
  #25 0x000000000916ae91 llvm::legacy::PassManager::run(llvm::Module&) /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/IR/LegacyPassManager.cpp:1681:3

But that's actually not the original situation I was investigating, so maybe it's another bug? (possibly same root cause, though)

Though the original issue I was investigating was from invalid `.debug_gnu_pubnames` (DIE offsets of 0, which prematurely terminates the `.debug_gnu_pubnames` list and produces a warning from `llvm-dwarfdump`), and by adding `assert(Offset)` in `llvm::DIE::getOffset` (initially I added it in the pubnames emission code, but generally it should be true that the offset of a DIE should not be queried until it's been computed, and no DIE has offset zero, because the offset is from the start of the CU contribution - so the headers come first and mean the DIE offset is always non-zero). It seems I still don't have a small reproduction for that exact issue, though.

The second test case provided above, that produces multiple DWO CUs can be reproduced as follows:

  $ clang++-tot ab-multi-cu.ll -gsplit-dwarf -c -O1 && llvm-dwarfdump-tot ab-multi-cu.o
  ab-multi-cu.o:  file format elf64-x86-64

  .debug_info contents:
  0x00000000: Compile Unit: length = 0x00000053, format = DWARF32, version = 0x0004, abbr_offset = 0x0000, addr_size = 0x08 (next unit at 0x00000057)

  0x0000000b: DW_TAG_compile_unit
                DW_AT_stmt_list   (0x00000000)
                DW_AT_comp_dir    ("/usr/local/google/home/blaikie/dev/scratch")
                DW_AT_GNU_pubnames        (true)
                DW_AT_GNU_dwo_name        ("ab-multi-cu.dwo")
                DW_AT_GNU_dwo_id  (0xe9d1660e0395035d)
                DW_AT_low_pc      (0x0000000000000000)
                DW_AT_high_pc     (0x000000000000000d)
                DW_AT_GNU_addr_base       (0x00000000)

  0x00000030:   DW_TAG_subprogram
                  DW_AT_low_pc    (0x0000000000000000)
                  DW_AT_high_pc   (0x000000000000000d)
                  DW_AT_name      ("main")

  0x00000041:     DW_TAG_inlined_subroutine
                    DW_AT_abstract_origin (0x000000000000007b "f1")
                    DW_AT_low_pc  (0x0000000000000004)
                    DW_AT_high_pc (0x0000000000000009)
                    DW_AT_call_file       ("/usr/local/google/home/blaikie/dev/scratch/b.cpp")
                    DW_AT_call_line       (3)
                    DW_AT_call_column     (0x03)

  0x00000055:     NULL

  0x00000056:   NULL
  0x00000057: Compile Unit: length = 0x00000027, format = DWARF32, version = 0x0004, abbr_offset = 0x0000, addr_size = 0x08 (next unit at 0x00000082)

  0x00000062: DW_TAG_compile_unit
                DW_AT_stmt_list   (0x0000004c)
                DW_AT_comp_dir    ("/usr/local/google/home/blaikie/dev/scratch")
                DW_AT_GNU_pubnames        (true)
                DW_AT_GNU_dwo_name        ("ab-multi-cu.dwo")
                DW_AT_GNU_dwo_id  (0xeb227ecffcd242c1)
                DW_AT_GNU_addr_base       (0x00000000)

  0x0000007b:   DW_TAG_subprogram
                  DW_AT_name      ("f1")
                  DW_AT_inline    (DW_INL_inlined)

  0x00000081:   NULL

In this case the second CU is OK (for the cross-CU inlining that's occurred), but it shouldn't have any `DWO_*` attributes, and the .dwo file shouldn't have a second CU in it (which it does after this patch) because Split DWARF doesn't have a good way to describe cross-CU references correctly once the CU is packaged in a dwp file. (this behavior is meant to be controlled by the `SplitDwarfCrossCUReferences` flag.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113741/new/

https://reviews.llvm.org/D113741