[llvm-bugs] [Bug 40188] New: [DebugInfo at O2] Bogus parameter value presented for struct argument

[via llvm-bugs]

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

            Bug ID: 40188
           Summary: [DebugInfo at O2] Bogus parameter value presented for
                    struct argument
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: CONFIRMED
          Keywords: wrong-debug
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: jeremy.morse.llvm at gmail.com
                CC: chackz0x12 at gmail.com, dblaikie at gmail.com,
                    greg.bedwell at sony.com,
                    international.phantom at gmail.com,
                    llvm-bugs at lists.llvm.org, paul.robinson at am.sony.com
            Blocks: 38768

Using r350008 and the command line "clang-8 -O2 -g test.cpp -o a.out
-fno-inline", in the code below a bogus value is reported for the value of
'eyelids' when entering the 'foo' function. The code:

--------8<--------
struct bees {
        int a;
        int b;
};

int
foo(struct bees eyelids)
{
        return eyelids.a + eyelids.b;
}

int
main()
{
        struct bees xyzzy = { 1, 2 };
        return foo(xyzzy);
}
-------->8--------

Gdbs interpretation on stepping into foo:

(gdb) frame
#0  foo (eyelids=...) at test.cpp:8
8       {
(gdb) print eyelids
$1 = {a = 1, b = 4195504}

Compiling with g++ 6.3 reports eyelids.b=2 at the same location. Examining
clangs output with llvm-dwarfdump, we generate the following expression for
"eyelids" for the body of "foo":

DW_OP_reg5 RDI, DW_OP_piece 0x4, DW_OP_reg0 RAX, DW_OP_piece 0x4

when the value of eyelids is actually only passed in rdi (upper and lower
portions). Compiling with g++ and -gstrict-dwarf correctly gives only
"DW_OP_reg5 RDI". The body of "foo" moves eyelids.b to eax initially, it
appears that the location of that fragment gets hoisted to cover the beginning
of the function, even when eax isn't def'd yet. I'm 95% confident the code that
does that is here [0], which appears to assume the first DBG_VALUE of a
parameter can have its location forwarded to the function start.

That assumption might have been valid given that there's code in SelectionDAG
[1] that emits DBG_VALUEs for parameters at the start of functions, although
for byvals only. Perhaps it used to produce entry DBG_VALUEs for every
parameter in the past?

There's a test in-tree that already exhibits this behaviour,
test/DebugInfo/ARM/partial-subreg.ll , which builds the 'self' parameter from
stack into registers over several instructions, but the location covers the
whole function, incorrectly. I ran into this problem when fiddling elsewhere,
the reproducer is to generalise the problem.

[0]
https://github.com/llvm-mirror/llvm/blob/6cd86b7cd2bb90a97d8a75196d6c0a4365c49a8b/lib/CodeGen/AsmPrinter/DebugHandlerBase.cpp#L219
[1]
https://github.com/llvm-mirror/llvm/blob/27f17bfee31bec92b918f4ca6a6f7a2a37e4d00c/lib/CodeGen/SelectionDAG/ScheduleDAGSDNodes.cpp#L818


Referenced Bugs:

https://bugs.llvm.org/show_bug.cgi?id=38768
[Bug 38768] [meta][DebugInfo] Umbrella bug for poor debug experiences
-- 
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/20181230/e17a60c3/attachment.html>