[llvm-bugs] [Bug 48087] New: Incorrect usage of DW_OP_constXXX on 32-bit targets

[via llvm-bugs]

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

            Bug ID: 48087
           Summary: Incorrect usage of DW_OP_constXXX on 32-bit targets
           Product: libraries
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: DebugInfo
          Assignee: unassignedbugs at nondot.org
          Reporter: labath at google.com
                CC: dblaikie at gmail.com, jdevlieghere at apple.com,
                    keith.walker at arm.com, llvm-bugs at lists.llvm.org,
                    paul_robinson at playstation.sony.com

Dwarf says (section 2.5.1.1. Literal Encodings of DWARF v5):
Operations other than DW_OP_const_type push a value with the generic type, and
if the value of a constant in one of these operations is larger than can be
stored in a
single stack element, the value is truncated to the element size and the
low-order bits are pushed on the stack.

[ In 2.5.1., "generic type" is defined as "an integral type that has the size
of an address on the target machine and unspecified signedness" ]

If we take this code:
void g(long long);
void f() {
  long long x = 0x4247;
  g(x);
  x = 0x474247424742ull;
  g(x);
}
And compile it (with optimizations) with clang for a 32-bit target, we get the
following location list for "x":
                     [0x00000000, 0x0000000f): DW_OP_consts +16967,
DW_OP_stack_value
                     [0x0000000f, 0x00000025): DW_OP_consts +78349988939586,
DW_OP_stack_value)

This usage is incorrect, because the result of DW_OP_consts should be truncated
to 4 bytes (size of an address). For the first expression, that's mostly fine,
but for the second value, this garbles/truncates the expression value.

gdb will display the truncated (wrong) value for x. lldb will display the
correct value, but only because it's handling of DW_OP_constXX opcodes is
non-conforming (I was about to fix it to make it conforming, before I
discovered this problem). I haven't checked what other consumers do.

gcc deals with this problem by using DW_OP_implicit_value for this variable:
                     [0x00000000, 0x0000001b): DW_OP_implicit_value 0x8 0x47
0x42 0x00 0x00 0x00 0x00 0x00 0x00
                     [0x0000001b, 0x00000031): DW_OP_implicit_value 0x8 0x42
0x47 0x42 0x47 0x42 0x47 0x00 0x00)

I guess llvm should do the same?

We can keep the symmetrical lldb bug for a while for backwards compatibility,
but it would be good to fix that one day....

-- 
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/20201105/edad56ec/attachment.html>