[llvm-bugs] [Bug 44275] New: Assertion `cast<DIExpression>(Expr)->isValid() && "not an expression"' for entry value for indirect parameter

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Dec 11 06:10:53 PST 2019


https://bugs.llvm.org/show_bug.cgi?id=44275

            Bug ID: 44275
           Summary: Assertion `cast<DIExpression>(Expr)->isValid() && "not
                    an expression"' for entry value for indirect parameter
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: DebugInfo
          Assignee: unassignedbugs at nondot.org
          Reporter: david.stenberg at ericsson.com
                CC: jdevlieghere at apple.com, keith.walker at arm.com,
                    llvm-bugs at lists.llvm.org,
                    paul_robinson at playstation.sony.com

Reproduced on trunk (987e7323fb53f968d5878483610fcf2319cdde86).

When compiling the following file:

    struct a {
      a(a &) {}
    };
    class b {
      a c;
    };
    class C {
    protected:
      C(int, int, b);
    };
    class d : C {
      d(int &, b);
    };
    int e;
    d::d(int &f, b g) : C(f, e, g) {}

using:

    $ clang++ -Xclang -femit-debug-entry-values foo.cpp -O2 -g -c

an assertion fails:

    clang-10: /path/to/monorepo/llvm/lib/CodeGen/MachineInstr.cpp:2019:
llvm::MachineInstrBuilder llvm::BuildMI(llvm::MachineFunction&, const
llvm::DebugLoc&, const llvm::MCInstrDesc&, bool, llvm::Register, const
llvm::MDNode*, const llvm::MDNode*): Assertion
`cast<DIExpression>(Expr)->isValid() && "not an expression"' failed.
    Stack dump:
    0.  Program arguments: /path/to/monorepo/build/bin/clang-10 -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name foo.cpp
-mrelocation-model static -mthread-model posix -mframe-pointer=none
-fmath-errno -fno-rounding-math -masm-verbose -mconstructor-aliases
-munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info
-fno-split-dwarf-inlining -debug-info-kind=limited -dwarf-version=4
-debugger-tuning=gdb -resource-dir /path/to/monorepo/build/lib/clang/10.0.0
-internal-isystem /usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/x86_64-linux-gnu
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/backward
-internal-isystem /usr/local/include -internal-isystem
/path/to/monorepo/build/lib/clang/10.0.0/include -internal-externc-isystem
/usr/include/x86_64-linux-gnu -internal-externc-isystem /include
-internal-externc-isystem /usr/include -O2 -fdeprecated-macro
-fdebug-compilation-dir /path/to/monorepo -ferror-limit 19 -fmessage-length 0
-fgnuc-version=4.2.1 -fobjc-runtime=gcc -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp
-femit-debug-entry-values -faddrsig -o foo.o -x c++ foo.cpp 
    1.  <eof> parser at end of file
    2.  Code generation
    3.  Running pass 'Function Pass Manager' on module 'foo.cpp'.
    4.  Running pass 'Live DEBUG_VALUE analysis' on function '@_ZN1dC2ERi1b'

This happens we are creating an entry value for:

    DBG_VALUE $rdx, $noreg, !"g", !DIExpression(DW_OP_deref), debug-location
!42; foo.cpp:15:16 line no:15

Currently DIExpression::isValid() assumes the following for entry values:

      return I->get() == expr_op_begin()->get() && I->getArg(0) == 1 && 
             getNumElements() == 2;

It is the (getNumElements() == 2) check which causes the verifier to fail, due
to presence of the DW_OP_deref. That check is there since we're missing things
in DwarfExpression, and perhaps other places, to correctly emit entry values in
those cases.

This is what GCC emits for this case:

    00000028 0000000000000000 000000000000000a (DW_OP_breg1 (rdx): 0)
    0000002e 000000000000000a 0000000000000040 (DW_OP_entry_value: (DW_OP_reg1
(rdx)))

This happens often for C++ programs, so if we are not able to fix this quickly
I think we should change LiveDebugValues so that we don't run into this issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20191211/29d6c088/attachment-0001.html>


More information about the llvm-bugs mailing list