This is an archive of the discontinued LLVM Phabricator instance.

[DebugInfo] Do not generate duplicated label debug info if it has been processed.
ClosedPublic

Authored by HsiangKai on Aug 9 2018, 1:39 AM.

Details

Summary

In DwarfDebug::collectEntityInfo(), if the label entity is processed in DbgLabels list, it means the label is not optimized out. There is no need to generate debug info for it with null position.

The bug is reported by vext01 in https://reviews.llvm.org/D45045#1190748

Diff Detail

Repository
rL LLVM

Event Timeline

HsiangKai created this revision.Aug 9 2018, 1:39 AM
HsiangKai updated this revision to Diff 159875.Aug 9 2018, 1:52 AM
vext01 added a comment.Aug 9 2018, 3:31 AM

Hi HsiangKai,

Thanks for looking into this.

I've applied this diff to my LLVM clone (again, just before you DILabel codegen stuff was reverted) and rebuilt, but I can still see 0x0 low_pcs in the resulting label.

$ ls -al `which clang`
lrwxrwxrwx 1 vext01 vext01 7 Aug  1 16:16 /home/vext01/research/llvm/inst.debug/bin/clang -> clang-7
$ ls -al `which clang-7`
-rwxr-xr-x 1 vext01 vext01 2102557136 Aug  9 10:54 /home/vext01/research/llvm/inst.debug/bin/clan
$ clang -O0 -g example.ll -o example.o
warning: overriding the module target triple with x86_64-unknown-linux-gnu [-Woverride-module]
1 warning generated.
$ dwarfdump example.o
...
< 2><0x00000041>      DW_TAG_label
                        DW_AT_name                  XXXYYYZZZ
                        DW_AT_decl_file             0x00000001 ./main.xxx
                        DW_AT_decl_line             0x00000001
                        DW_AT_low_pc                0x00000000
...

Do you have this change in a svn or git branch somewhere? There was some fuzz applying the diff, which might be the cause.

aprantl added inline comments.Aug 10 2018, 4:01 PM
lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
1051

If this processes only variables, why return a set of InlinedEntities instead of InlinedVariables?

lib/CodeGen/AsmPrinter/DwarfDebug.cpp
1505

this is equivalent to

else {
  auto *DL = cast<DILabel>(DN); // llvm::cast asserts automatically.
  Scope = DL->getScope();
}
HsiangKai added inline comments.Aug 12 2018, 10:51 PM
lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
1051

DILocalVariable and DILabel are both DINode. So, I combined InlinedVariable and InlinedLabel into InlinedEntity.
In this way, I have no need to allocate two separate ‘Processed’ sets for them. It is cleaner to check them processed or not.

So, there is no InlinedVariable any more in this patch.

lib/CodeGen/AsmPrinter/DwarfDebug.cpp
1505

I keep the symmetric form of these if condition. It is cleaner to express the intension that there are two kinds of debug entity to process. If there is another debug entity to process in the future, it could add another if condition for it.

Hi HsiangKai,

Thanks for looking into this.

I've applied this diff to my LLVM clone (again, just before you DILabel codegen stuff was reverted) and rebuilt, but I can still see 0x0 low_pcs in the resulting label.

$ ls -al `which clang`
lrwxrwxrwx 1 vext01 vext01 7 Aug  1 16:16 /home/vext01/research/llvm/inst.debug/bin/clang -> clang-7
$ ls -al `which clang-7`
-rwxr-xr-x 1 vext01 vext01 2102557136 Aug  9 10:54 /home/vext01/research/llvm/inst.debug/bin/clan
$ clang -O0 -g example.ll -o example.o
warning: overriding the module target triple with x86_64-unknown-linux-gnu [-Woverride-module]
1 warning generated.
$ dwarfdump example.o
...
< 2><0x00000041>      DW_TAG_label
                        DW_AT_name                  XXXYYYZZZ
                        DW_AT_decl_file             0x00000001 ./main.xxx
                        DW_AT_decl_line             0x00000001
                        DW_AT_low_pc                0x00000000
...

Do you have this change in a svn or git branch somewhere? There was some fuzz applying the diff, which might be the cause.

After syncing with vext01 by private messages, the difference is caused by FastISel. By default, X86 uses FastISel under -O0. I prepared a patch for FastISel in D50622.

Any comments?

@aprantl, do you agree my comments?

aprantl added inline comments.Aug 28 2018, 8:58 AM
lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
1051

Okay.

Is there anything I should address?

Without this patch, it will generate two DW_TAG_label for the same label if retainedNodes also contains the label.
This patch will record processed labels in 'Processed' DenseSet to avoid generating duplicated DW_TAG_label for them.

aprantl accepted this revision.Sep 5 2018, 8:32 AM
This revision is now accepted and ready to land.Sep 5 2018, 8:32 AM

I have a bitcode example that crashes with llc badfile -split-dwarf-file some.dwo.
Reverting, will upload the file once it's done minimizing.

Hmm, so thinking about it, since this is a clang change and the crash reproduces with llc, this is just generating code that triggers an existing LLVM bug.

I think we still need to revert it for now as it triggers a clang crash :-(

llc: /usr/local/google/home/sammccall/src/llvm/lib/MC/MCExpr.cpp:176: llvm::MCSymbolRefExpr::MCSymbolRefExpr(const llvm::MCSymbol *, llvm::MCSymbolRefExpr::VariantKind, const llvm::MCAsmInfo *, llvm::SMLoc): Assertion `Symbol' failed.
Stack dump:
0.	Program arguments: bin/llc bugpoint-reduced-named-md.bc -split-dwarf-file out.dwo 
#0 0x0000000003659b19 llvm::sys::PrintStackTrace(llvm::raw_ostream&) /usr/local/google/home/sammccall/src/llvm/lib/Support/Unix/Signals.inc:490:11
#1 0x0000000003659cc9 PrintStackTraceSignalHandler(void*) /usr/local/google/home/sammccall/src/llvm/lib/Support/Unix/Signals.inc:554:1
#2 0x0000000003657f26 llvm::sys::RunSignalHandlers() /usr/local/google/home/sammccall/src/llvm/lib/Support/Signals.cpp:66:5
#3 0x000000000365a2e7 SignalHandler(int) /usr/local/google/home/sammccall/src/llvm/lib/Support/Unix/Signals.inc:353:1
#4 0x00007f8f521d20c0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x110c0)
#5 0x00007f8f50d63fcf gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x32fcf)
#6 0x00007f8f50d653fa abort (/lib/x86_64-linux-gnu/libc.so.6+0x343fa)
#7 0x00007f8f50d5ce37 (/lib/x86_64-linux-gnu/libc.so.6+0x2be37)
#8 0x00007f8f50d5cee2 (/lib/x86_64-linux-gnu/libc.so.6+0x2bee2)
#9 0x0000000002e36e0f llvm::MCSymbolRefExpr::MCSymbolRefExpr(llvm::MCSymbol const*, llvm::MCSymbolRefExpr::VariantKind, llvm::MCAsmInfo const*, llvm::SMLoc) /usr/local/google/home/sammccall/src/llvm/lib/MC/MCExpr.cpp:177:1
#10 0x0000000002e36eb6 llvm::MCSymbolRefExpr::create(llvm::MCSymbol const*, llvm::MCSymbolRefExpr::VariantKind, llvm::MCContext&, llvm::SMLoc) /usr/local/google/home/sammccall/src/llvm/lib/MC/MCExpr.cpp:182:10
#11 0x0000000000c12368 llvm::MCSymbolRefExpr::create(llvm::MCSymbol const*, llvm::MCContext&) /usr/local/google/home/sammccall/src/llvm/include/llvm/MC/MCExpr.h:323:5
#12 0x00000000025e4262 llvm::AddressPool::emit(llvm::AsmPrinter&, llvm::MCSection*) /usr/local/google/home/sammccall/src/llvm/lib/CodeGen/AsmPrinter/AddressPool.cpp:60:15
#13 0x000000000250dfa9 llvm::DwarfDebug::emitDebugAddr() /usr/local/google/home/sammccall/src/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:2380:1
#14 0x000000000250be72 llvm::DwarfDebug::endModule() /usr/local/google/home/sammccall/src/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:896:11
#15 0x00000000024dd8ee llvm::AsmPrinter::doFinalization(llvm::Module&) /usr/local/google/home/sammccall/src/llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:1450:12
#16 0x0000000002cf8bf4 llvm::FPPassManager::doFinalization(llvm::Module&) /usr/local/google/home/sammccall/src/llvm/lib/IR/LegacyPassManager.cpp:1596:16
#17 0x0000000002cf95e3 (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) /usr/local/google/home/sammccall/src/llvm/lib/IR/LegacyPassManager.cpp:1670:16
#18 0x0000000002cf8d9e llvm::legacy::PassManagerImpl::run(llvm::Module&) /usr/local/google/home/sammccall/src/llvm/lib/IR/LegacyPassManager.cpp:1754:16
#19 0x0000000002cf9891 llvm::legacy::PassManager::run(llvm::Module&) /usr/local/google/home/sammccall/src/llvm/lib/IR/LegacyPassManager.cpp:1785:3
#20 0x0000000000bd8a5c compileModule(char**, llvm::LLVMContext&) /usr/local/google/home/sammccall/src/llvm/tools/llc/llc.cpp:600:41
#21 0x0000000000bd695d main /usr/local/google/home/sammccall/src/llvm/tools/llc/llc.cpp:351:13
#22 0x00007f8f50d512b1 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b1)
#23 0x0000000000bd603a _start (bin/llc+0xbd603a)

Hmm, so thinking about it, since this is a clang change and the crash reproduces with llc, this is just generating code that triggers an existing LLVM bug.

I think we still need to revert it for now as it triggers a clang crash :-(

llc: /usr/local/google/home/sammccall/src/llvm/lib/MC/MCExpr.cpp:176: llvm::MCSymbolRefExpr::MCSymbolRefExpr(const llvm::MCSymbol *, llvm::MCSymbolRefExpr::VariantKind, const llvm::MCAsmInfo *, llvm::SMLoc): Assertion `Symbol' failed.
Stack dump:
0.	Program arguments: bin/llc bugpoint-reduced-named-md.bc -split-dwarf-file out.dwo 
#0 0x0000000003659b19 llvm::sys::PrintStackTrace(llvm::raw_ostream&) /usr/local/google/home/sammccall/src/llvm/lib/Support/Unix/Signals.inc:490:11
#1 0x0000000003659cc9 PrintStackTraceSignalHandler(void*) /usr/local/google/home/sammccall/src/llvm/lib/Support/Unix/Signals.inc:554:1
#2 0x0000000003657f26 llvm::sys::RunSignalHandlers() /usr/local/google/home/sammccall/src/llvm/lib/Support/Signals.cpp:66:5
#3 0x000000000365a2e7 SignalHandler(int) /usr/local/google/home/sammccall/src/llvm/lib/Support/Unix/Signals.inc:353:1
#4 0x00007f8f521d20c0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x110c0)
#5 0x00007f8f50d63fcf gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x32fcf)
#6 0x00007f8f50d653fa abort (/lib/x86_64-linux-gnu/libc.so.6+0x343fa)
#7 0x00007f8f50d5ce37 (/lib/x86_64-linux-gnu/libc.so.6+0x2be37)
#8 0x00007f8f50d5cee2 (/lib/x86_64-linux-gnu/libc.so.6+0x2bee2)
#9 0x0000000002e36e0f llvm::MCSymbolRefExpr::MCSymbolRefExpr(llvm::MCSymbol const*, llvm::MCSymbolRefExpr::VariantKind, llvm::MCAsmInfo const*, llvm::SMLoc) /usr/local/google/home/sammccall/src/llvm/lib/MC/MCExpr.cpp:177:1
#10 0x0000000002e36eb6 llvm::MCSymbolRefExpr::create(llvm::MCSymbol const*, llvm::MCSymbolRefExpr::VariantKind, llvm::MCContext&, llvm::SMLoc) /usr/local/google/home/sammccall/src/llvm/lib/MC/MCExpr.cpp:182:10
#11 0x0000000000c12368 llvm::MCSymbolRefExpr::create(llvm::MCSymbol const*, llvm::MCContext&) /usr/local/google/home/sammccall/src/llvm/include/llvm/MC/MCExpr.h:323:5
#12 0x00000000025e4262 llvm::AddressPool::emit(llvm::AsmPrinter&, llvm::MCSection*) /usr/local/google/home/sammccall/src/llvm/lib/CodeGen/AsmPrinter/AddressPool.cpp:60:15
#13 0x000000000250dfa9 llvm::DwarfDebug::emitDebugAddr() /usr/local/google/home/sammccall/src/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:2380:1
#14 0x000000000250be72 llvm::DwarfDebug::endModule() /usr/local/google/home/sammccall/src/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:896:11
#15 0x00000000024dd8ee llvm::AsmPrinter::doFinalization(llvm::Module&) /usr/local/google/home/sammccall/src/llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:1450:12
#16 0x0000000002cf8bf4 llvm::FPPassManager::doFinalization(llvm::Module&) /usr/local/google/home/sammccall/src/llvm/lib/IR/LegacyPassManager.cpp:1596:16
#17 0x0000000002cf95e3 (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) /usr/local/google/home/sammccall/src/llvm/lib/IR/LegacyPassManager.cpp:1670:16
#18 0x0000000002cf8d9e llvm::legacy::PassManagerImpl::run(llvm::Module&) /usr/local/google/home/sammccall/src/llvm/lib/IR/LegacyPassManager.cpp:1754:16
#19 0x0000000002cf9891 llvm::legacy::PassManager::run(llvm::Module&) /usr/local/google/home/sammccall/src/llvm/lib/IR/LegacyPassManager.cpp:1785:3
#20 0x0000000000bd8a5c compileModule(char**, llvm::LLVMContext&) /usr/local/google/home/sammccall/src/llvm/tools/llc/llc.cpp:600:41
#21 0x0000000000bd695d main /usr/local/google/home/sammccall/src/llvm/tools/llc/llc.cpp:351:13
#22 0x00007f8f50d512b1 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b1)
#23 0x0000000000bd603a _start (bin/llc+0xbd603a)

The bug is fixed in https://reviews.llvm.org/D51908.
Thanks for your test case.

HsiangKai closed this revision.Nov 30 2018, 12:18 AM

This revision is committed to master branch.
I forgot to add "Differential Revision" in commit message. So, this revision is not closed automatically.