[PATCH] D29310: Fix DwarfDebug assertions with LTO mixing -g and -gmlt

[David Blaikie via llvm-commits]

On Tue, Jan 31, 2017 at 3:05 PM Paul Robinson via Phabricator <
reviews at reviews.llvm.org> wrote:

> probinson added inline comments.
>
>
> ================
> Comment at: test/DebugInfo/X86/dbg-abstract-vars-g-gmlt.ll:1
> +; RUN: llc < %s -filetype=obj | llvm-dwarfdump - -debug-dump=info |
> FileCheck %s
> +;
> ----------------
> dblaikie wrote:
> > Here's the simplest example I have for this (also doesn't require
> optimizations either at compile time or after the link step (though they
> can be used to tidy up the IR a little):
> >
> >   // first file
> >   void f1();
> >   inline __attribute__((always_inline)) void f2(int) {
> >     f1();
> >   }
> >   void f3() {
> >     f2();
> >   }
> >
> >   // second file
> >   void f() {
> >   }
> >
> I have not been able to get your example to crash on an unmodified
> compiler, can you provide more details?
>

Hmm. Seems to be working for me thusly (maybe I was missed some details
first time around):

blaikie at blaikie-linux:~/dev/scratch$ cat AbstVar.cpp
#ifdef P1
void f1();
inline __attribute__((always_inline)) void f2(int) {
  f1();
}
void f3() {
  f2(0);
}
#else
void f() {
}
#endif
blaikie at blaikie-linux:~/dev/scratch$ clang-tot -emit-llvm -S -DP1 -g
AbstVar.cpp -o AbstVar-1.ll && clang-tot -emit-llvm -S -gmlt AbstVar.cpp -o
AbstVar-2.ll && llvm-link-tot AbstVar-{1,2}.ll -S -o AbstVar-link.ll &&
llc-tot AbstVar-link.ll -o /dev/null -filetype=obj 2>&1
llc-tot: llvm/src/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1223: virtual void
llvm::DwarfDebug::endFunction(const llvm::MachineFunction *): Assertion
`AbstractVariables.empty()' failed.
#0 0x0000000003fedf1c (llc-tot+0x3fedf1c)
#1 0x0000000003fee409 (llc-tot+0x3fee409)
#2 0x0000000003fec783 (llc-tot+0x3fec783)
#3 0x0000000003fee764 (llc-tot+0x3fee764)
#4 0x00007f3e1eb76330 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x10330)
#5 0x00007f3e1dc83c37 gsignal
/build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0
#6 0x00007f3e1dc87028 abort
/build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0
#7 0x00007f3e1dc7cbf6 __assert_fail_base
/build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0
#8 0x00007f3e1dc7cca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2)
#9 0x0000000003178220 (llc-tot+0x3178220)
#10 0x000000000314a7d6 (llc-tot+0x314a7d6)
#11 0x0000000002bd4fc1 (llc-tot+0x2bd4fc1)
#12 0x00000000033c9ee1 (llc-tot+0x33c9ee1)
#13 0x00000000037cae8f (llc-tot+0x37cae8f)
#14 0x00000000037cb1a5 (llc-tot+0x37cb1a5)
#15 0x00000000037cb93a (llc-tot+0x37cb93a)
#16 0x00000000037cb466 (llc-tot+0x37cb466)
#17 0x00000000037cbe51 (llc-tot+0x37cbe51)
#18 0x0000000001da725e (llc-tot+0x1da725e)
#19 0x0000000001da56eb (llc-tot+0x1da56eb)
#20 0x00007f3e1dc6ef45 __libc_start_main
#21 0x0000000001da5029 (llc-tot+0x1da5029)
Stack dump:
0.      Program arguments: llc-tot AbstVar-link.ll -o /dev/null
-filetype=obj
1.      Running pass 'Function Pass Manager' on module 'AbstVar-link.ll'.
2.      Running pass 'X86 Assembly Printer' on function '@_Z1fv'
Aborted (core dumped)


>
> ================
> Comment at: test/DebugInfo/X86/dbg-value-g-gmlt.ll:1
> +; RUN: llc -filetype=obj < %s | llvm-dwarfdump - -debug-dump=info |
> FileCheck %s
> +;
> ----------------
> dblaikie wrote:
> > Interestingly, this still seems to trigger the assert:
> >
> >   void f()
> >   void foo(int param) {
> >     if (param)
> >       f();
> >   }
> >
> >   void foo(int);
> >   void bar() {
> >     foo(0);
> >   }
> >
> > Which is vaguely worrying - since in this case the call to foo is
> not/cannot be optimized away, so I'm not sure what the assertion is telling
> us here. There should be instructions for the function & so we shouldn't be
> in that codepath.
> Why can't it be inlined away?  bar() calls foo(), foo() gets inlined into
> bar(), the constant 0 parameter is propagated to the 'if', the condition is
> guaranteed false therefore the 'if/then' goes away, poof all gone.  Except
> for the dbg.value describing the inlined copy of 'param'.
>

Oh, good point. Great - then that's a good reproduction :)


>
>
> https://reviews.llvm.org/D29310
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170201/b79db39f/attachment.html>