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

Wed May 25 14:05:15 PDT 2022

ayermolo added a comment.

In D113741#3207125 <https://reviews.llvm.org/D113741#3207125>, @dblaikie wrote:

> 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.

This does look like a stack trace for D124892 <https://reviews.llvm.org/D124892>.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113741